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I. INTRODUCTION 



A. OVERVIEW 

An expert system is a subspecialty in the field of artificial intelligence which has 
relevance for use in a military environment Significant advances have been made in 
the area of expert systems, and a host of military applications are expected. [Ref. 1: p. 
29] Expert systems are computer programs that duplicate to a certain degree the kinds 
of conclusions and results that an expert would make given the facts and 
circumstances. Expert systems are designed to solve problems, to give advice, and to 
provide a rationale for the decision reached. 

Although there have been some impressive results demonstrated by expert 
systems and several commercial examples exist, the most well known expert systems 
have been limited to applications in medical diagnosis, mineral prospecting, chemical 
analysis and computer configuration. The developers of these commercial systems 
make no pretext that these expert systems duplicate the reasoning process that experts 
commonly use in problem solving; instead they have concentrated on achieving results 
similar to those of an expert. [Ref. 1: p. 36] Current applications of expert systems 
have been limited to non-military environments. The aim of this thesis is to apply the 
expert systems approach to a stochastic non-repetitive problem, specifically, a 
simulated air defense scenario. 

B. RELEVANCE OF EXPERT SYSTEMS TO THE MILITARY 

The air defense mission for U.S. Military Forces is characterized by a 
requirement for calculated, rapid and aggressive decision making in a non-structured 
environment. The decision to employ a particular weapon system to thwart a 
projected threat must be based upon a knowledge of assets available and some type of 
information on the enemy. The multitude of variables encapsulated within the decision 
making requirement and the necessity for sudden immediate responses to potential 
threats forces the weapons employment commander to be thoroughly familiar with all 
facets of the air defense environment. A delay in countering an enemy action can be as 
deadly as a misapplication of friendly forces. The task of providing air defense is 
becoming increasingly more difficult in todays high technology era. Sophisticated 
enemy weapon platforms can penetrate a surveillance zone and strike at a vital area in 
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a matter of minutes. A complex organization of defense assets exists within the 
military command and control structure to combat these platforms. However, the 
means to circumvent or minimize losses is predicated upon the commanders knowledge 
and ability to manage all available resources. The commander is in effect tasked to be 
an 'expert' in the decision support arena. 

In any high stress, high information rate situation, human decision makers can 
become overloaded and unable to assimilate and use all of the data that is available to 
them. This is particularly true in sensot interpretation and combat management where 
data received must be evaluated and used effectively in managing weapons and making 
tactical decisions under the auspices of time constraints. Expert systems offer the 
potential for application in decision support by providing interpretation aids, automatic 
analysis or situation assessment. In these applications, expert systems would 
automatically assimilate the latest data from such sources as sensors, intelligence 
reports and human decision makers, and could provide plausible hypothesis about 
current situations to operators, planners, and other human decision makers. [Ref. 1: p. 
42] 

Expert systems can best be used in critical military tasks where the development 
of new machine technologies will aid in the use and application of strategic computing. 
Some of the goals of strategic computing include: [Ref. 2: p. 82] 

• Enable the operation of military systems under critical constraints such as time, 
information, and overload 

• Enable the management of forces/ resources under constraints of information 
overload, geographic distribution, and cost of operations 

• Facilitate the design, manufacture and maintenance of defense systems within 
time, performance, “quality, reliability and cost constraints 

Utilizing expert systems in a strategic computer environment will allow the 
military commander to exercise judgements and decisions more effectively if more 
information is able to be processed for interpretation, which is especially critical when 
dealing with constraints such as time information overload. Expert systems might also 
enable military personnel to more efficiently and effectively manage the forces and/or 
resources that may be involved in a scenario. Expert systems can process the 
information presented under multiple parameters and constraints, putting forth a 
recommended course of action to take. This would give military personnel a fast, 
responsive course of action that may be taken based upon the operating environment. 
Using expert systems in this manner might allow military personnel to improve their 
skills, knowledge, and training in different environments. 
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C. THESIS RESEARCH QUESTIONS 

The primary goal and emphasis of this thesis is to determine the feasibility of 
using the expert systems approach to solve a problem in a stochastic non-repetitive 
environment. To accomplish this goal we needed to research and answer two primary 
questions: 

1. Can an expert systems approach be applied to problems that are characterized 
by a non-repetitive stochastic environment? 

2. Can a developed expert system prototype be interfaced with an external system 
in order to draw the required inputs for processing and analysis? 

The analysis, answers, and conclusions to these questions will enable us to determine 

the viability of any future extensions of our thesis where the incorporation of actual 

sensor information could be used directly as input to an expert system; 

D. DEVELOPMENT OF AN EXPERT SYSTEMS PROTOTYPE 

The expert systems approach used in this thesis is based upon multiple 
parametric representations of activities that may transpire in a stochastic non-repetitive 
environment. The circumstances and information encountered within this environment 
will have to be interpreted by the expert system prototype constructed. The facts and 
information representing the environment will be developed and presented through 
data base files. 

The prototype is built on the premise that it will use information about a 
developing situation represented in data base files, and will ascertain a correct course 
of action that should be taken in response to .the scenario presented. The non- 
repetitive variables to be used by the system is data that would actually be gathered by 
sensors in a real world scenario. To replicate different types of situations, database 
files will be constructed that will 'feed' the required inputs to the expert system 
prototype for processing, analysis, and decision recommendation. In addition to data 
files stored within the expert system prototype, a database file will also be built using 
DBASE III Plus in order to test the use and application of an external system 
interfacing with an expert system prototype. By using an external system such as 
DBASE III Plus, an attempt will be made to ascertain wiiether or not it is feasible that 
expert systems w r hich might be applicable to military environments can be integrated 
and used with computer systems external and independent of an expert system. 

In order to develop an expert system prototype for use in this thesis the 
Arity! Expert Development Shell as w T ell as Prolog were utilized. The Arity! Expert 
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Development Shell is a collection of developmental tools which provided the basis for 
constructing an expert system prototype. The power of the shell was enhanced by 
interleaving it with a Prolog interpreter. 
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II. CONSTRUCTION OF AN EXPERT SYSTEM 



A. ARTIFICIAL INTELLIGENCE 

Artificial Intelligence is a growing set of computer problem-solving techniques 
that are developed to imitate human decision-making processes. There are many 
definitions of artificial intelligence (AI) put forth by AI experts, some of which include: 

• Marvin Minsky, Donner Professor of Science at the Massachusetts Institute of 
Technology arid founder of the field of AI, has stated that "artificial intelligence 
is the science of making machines do things that would require intelligence if 
done by men." [Ref. 3: p. 4] 

• Patrick H. Winston, director of the artificial intelligence laboratory at the 
Massachusetts Institute of technology, writes: "The goals of artificial 
intelligence are to make computers more useful and to understand the principles 
which make intelligence possible." [Ref. 4: p. 1] 

• Nils Nilson, Chairman of the Department of Computer Science at Stanford 
University, says: "The field of Artificial Intelligence has as its main tenant that 
there are' indeed common processes that underlie thinking and perceiving, and 
furthermore that those processes can be understood and studied scientifically." 
[Ref. 5: p. 8] 

'• Bruce G. Buchanan, adjunct professor of computer science research; and 
Edward A. Feigenbaum, principal investigator at the Heuristic Programming 
Project; both oT Stanford University write: "Artificial Intelligence research is 
that part of computer science that investigates symbolic, nonalgorithmic 
reasoning processes and the representation or symbolic knowledge for use in 
machine inference." [Ref. 6: p. 15] 

The field of artificial intelligence offers distinctive approaches to complex 
problem solving. In conventional computing, it is the programmer who creates 
computer program instructions that follow solution paths for each situation presented. 
The solution path is planned by the programmer using structured predictable steps, 
which enable the solving of problems that require a large amount of data to be 
processed. Artificial intelligence uses techniques that are helpful in solving complex 
problem-symbolic processing. The symbols processed by artificial intelligence 
programs represent real-world entities, and instead of simply performing calculations, 
artificial intelligence programs manipulate the relationships among the symbols. 
[Ref. 5: p. 52] 



B. EXPERT SYSTEMS: AN OVERVIEW 

The area of expert systems investigates methods and techniques for the 
construction of man-machine systems that have specialized decision-making expertise. 
Expertise consists of knowledge about a particular domain, understanding of the 
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domain problem, and skills at solving the problems. Knowledge in any specialty can 
be gained from two areas: public and private. Public knowledge involves the published 
definitions, facts and theories of which textbooks and references in the discipline of 
study are typically composed. Expertise usually involves more than just public 
knowledge, human experts generally possess private knowledge that has not found its 
way into published literature. This private knowledge consists largely of rules of 
thumb used by experts, commonly known as heuristics. Heuristics enable the human 
expert to make educated guesses when necessary, to recognize promising approaches to 
problems, and to deal effectively with incomplete or erroneous data. Elucidating and 
reproducing such knowledge is the central task in constructing expert systems. 
[Ref. 7: p. 4] Expert systems differ from both conventional data processing systems and 
systems developed in other branches of artificial intelligence. A I applications generally 
involve several distinguishing features, which include symbolic representation, heuristic 
search, and symbolic inference. Expert systems also differ from the broad range of A I 
in several aspects. First, they emphasize domain-specific problem solving strategies; 
Second, they employ self-knowledge to reason about their own inference processes and 
provide explanations or justifications for the conclusions reached; Third, they solve 
problems that generally fall into one of the following categories: interpretation, 
prediction, diagnosis, debugging, design, planning, monitoring, repair, instruction, or 
control. As a result of these distinctions, expert systems represent an area of AI 
research that involves paradigms, tools, and system development strategies. [Ref. 7: p. 
52] • . 

Using the above parameters an expert system can be defined as a knowledge- 
intensive program that solves problems that normally require a human expert. An 
expert system performs many of the reasoning functions an expert does such as asking 
relevant questions and explaining its reasoning. According to Frederick Hayes-Roth, 
characteristics common to all expert systems are: [Ref. 8: p. 264] 

• They reason heuristically, using what experts consider effective rules of thumb 

• Thev interact with humans in appropriate ways, including the use of natural 
languages 

• They manipulate and reason about symbolic descriptions 

• They function with erroneous data and uncertain judgemental rules 

• They contemplate multiple competing hypothesis simultaneously 

• They explain why they are asking questions 

• They justify their conclusions 
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Compared to a human expert today's expert systems appear narrow, brittle, and 
shallow lacking a human experts breadth of knowledge and understanding of 
fundamental principles. Expert systems today replicate the human decision-making 
process rather grossly. They make major decisions by elucidating many of the relevant 
criteria and by making many of the educated guesses that human experts might make if 
forced to verbalize their thought processes. Additionally, today's expert systems do not 
learn from experience. [Ref. 8: p. 264] 

C. BASIC CONCEPTS OF PROBLEM SOLVING 

The basic concepts of intelligently approaching problem-solving solutions shown 
in Figure 2.1 are the ideas that motivate and explain the aspects of knowledge resident 
in expert systems. The central notion of intelligent problem-solving is that a system 
must construct its solutions selectively and efficiently for given alternatives.. When the 
expert is resource limited, he needs to search his alternatives in order to achieve high 
performance by using knowledge acquired to effectively and efficiently solve his 
problem. [Ref. 7: p. 19] In most cases, experts face problems that are not easily 
formalized or do not have algorithmic solutions, and normally, heuristic methods must 
be used. Hence, effective solutions depend on the timely use of knowledge to identify 
potential decisions that are promising and rule out unpromising ones. The first three 
concepts in Figure 2. 1 address how an expert can develop the primacy of knowledge 
that must be resident in an expert system. The fourth and fifth concepts are methods 
that the expert can follow to aid in developing a more efficient knowledge base and to 
increase the ability of the system to solve more difficult problems. 

D. KNOWLEDGE ENGINEERING 

Knowledge engineering is the term that has been adopted by researchers for the 
discipline of formulating knowledge in expert systems. The burden of uncovering and 
formalizing the experts' knowledge is incumbent upon the knowledge engineer. 
Through an extended series of interactions with an expert, the knowledge engineer 
should be able to define the problems to be attacked, discover the basic concepts 
involved, and develop rules that express the relationships that exist between these basic 
concepts. The term knowledge engineering combines scientific, technological and 
methodology elements. One of the principles of knowledge engineering is that expert 
performance rarely conforms to some algorithmic process. The essential tasks of 
knowledge engineering is extracting, articulating, and computerizing the experts 
knowledge. 
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1. Knowledge = Facts + Beliefs + Heuristics 

2. Success = Finding a good enough answer with the resources 
available 

3. Search efficiency directly effects success 

4. Aids to Efficiency: 

a. applicable, correct, and discriminating knowledge 

b. rapid elimination of "blind alleys" 

c. elimination of redundant computation 

d. increased speed of computer operation 

e. multiple, cooperative sources of knowledge 

f. reasoning at varying levels of abstraction 

5. Sources of increased problem difficulty 

a. erroneous data or knowledge 

b. dynamically changing data 

c. the number of possibilities to evaluate 

d. complex procedures for ruling out possibilities 



Figure 2.1 Basic Concepts of Problem Solving. 

Knowledge in the abstract consists of descriptions, which are known as 
relationships, and procedures in some basic domain. A knowledge base contains 
particular descriptions which are known as relationships. Knowledge is what enables a 
human expert to solve difficult problems in a precise manner, the solution to which 
may be determined in many forms: empirically, heuristically, and causality. Knowledge 
engineering addresses the problem of developing and building skilled computer systems 
which first extract the experts knowledge, then organize it in an effective 
implementation. [Ref. 7: p. 13] 

E. TYPES OF EXPERT SYSTEMS 

Most expert systems fall into one of several generic types, each of w r hich will be 
briefly discussed herein. Interpretation systems infer situation descriptions from 
observations, which includes surveillance, speech understanding, image analysis, 
chemical structure elucidation, signal interpretation, and different types of intelligence 
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analysis. An interpretation system explains stochastic data by assigning symbolic 
meanings describing the situation or system state accounting for the data. 

Prediction systems infer likely consequences from given situations. This category 
includes weather forecasting, demographic predictions, traffic predictions, crop 
estimations, and military forecasting. A prediction system typically employs a 
parametric dynamic model with parameter values that are fitted to the given situation. 

Diagnosis systems infer system malfunctions from observables. This category 
includes medical, electronic, mechanical, and software diagnosis. Diagnosis systems 
typically relate observed behavioral irregularities with underlying causes using one of 
two techniques. The first method uses a table of associations between behaviors and 
diagnoses. The second method combines knowledge of system design with knowledge 
of potential flaws in design, implementation, or components which generate candidate 
malfunctions that are consistent with the observations. 

Design systems construct descriptions of objects that will satisfy the constraints 
of the design problem. Such problems include circuit layout, building design, and 
budgeting. Design systems construct descriptions of objects that are in various 
relationship w r ith one another and that verify that the configurations conform to stated 
constraints. 

Planning systems design actions. These type of systems specialize in problems of 
design concerned with objects that perform functions. They include automatic 
programming as well as robot, project, route, communication, and military planning 
problems. 

Monitoring systems compare observations of system behavior to features that are 
crucial to successful plan outcomes. These crucial features correspond to potential 
flaws that may be present in the plan. Generally, monitoring systems identify 
vulnerabilities in two ways. The first type of vulnerability corresponds to an assumed 
condition whose violation would nullify the plan's rationale. The second type of 
vulnerability arises when some potential effect of the plan violates a planning 
constraint. Many computer-aided monitoring systems exist for nuclear power plants, 
air traffic, disease, and regulatory fiscal management tasks. 

Debugging systems prescribe remedies for malfunctions. These systems rely on 
planning, design, and prediction capabilities to create specifications or 
recommendations that will help correct a diagnosed problem. Computer-aided 
debugging systems are available in the form of intelligent knowledge base and text 
editors, although none yet qualify as an expert system. 
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Repair systems develop and execute plans that administer a remedy for some 
diagnosed problems. Some of these systems incorporate debugging, planning, and 
execution capabilities. Computer-aided systems are occuring in the domains of 
automotive, network, avionic, and computer maintenance, however, expert systems are 
just now entering this domain. 

Instruction systems debug and diagnose behaviors. They incorporate diagnosis 
and debugging subsystems that specifically address certain problems. These systems 
begin by constructing a hypothetical description of the knowledge pertaining to the 
problem, then diagnose weakness in the knowledge and identify an appropriate remedy. 

The last type of system is called control. An expert control system adaptively 
governs the overall behavior of a particular system. In order to accomplish this a 
control system must repeatedly interpret the current situation, predict the future, 
diagnose the causes of anticipated problems, formulate a remedial plan, and monitor its 
execution to ensure success has been achieved. Problems addressed by control systems 
include air traffic control, business management, mission control and battlefield 
management. [Ref. 7: pp. 13-16] 

F. A FRAMEWORK FOR EXPERT SYSTEMS 

One of the most important aspects of an expert system is that it can make 
decisions or help people make decisions. Using this basic capability of an expert 
system, the essential framework behind expert systems can be illustrated. One of the 
characteristics of an expert system is that emphasis is on qualitative logical reasoning, 
vice quantitative calculations that are used in most other type of programs. Logical 
inference uses logical data, and consequently, the database of an expert system may or 
may not contain numerical data. The logical data in an expert system is commonly 
known as the knowledge base. 

One of the key features to a knowledge base is that its contents are not just 
abstract symbols like numbers or conditional probabilities. Another important 
component of a knowledge base is a body of facts which represents the way in which 
concepts are related to each other. In expert systems, the aim is to represent meaning 
explicitly by recording the relationship in a form that the computer can exploit, and 
not by reducing data to abstract quantities. [Ref. 9: p. 129] 

Figure 2.2 is a schematic representation of the many elements found in an expert 
system. [Ref. 9: p. 131] The most primitive element shared by all other computer 
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Decisions 




Class Knowledge 



Figure 2.2 Schematic Representation of an Expert System. 

programs is the symbol. Symbols are simply character strings which stand for or 
suggest something by reason of relationship, association, convention or accidental 
resemblance. When elements are progressively added, the ability of these symbols 
becomes richer and much more useful. After the descriptions and relationships have 
been instantiated, the rules of the knowledge base are constructed. Given data, the 
rules should be capable of making inferences under the auspices of some type of 
control process. A skillful decision maker does not apply rules blindly to a situation, 
but rather in a controlled manner, and an expert system must be similary controlled. 
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The inference engine of a knowledge based decision process usually provides this 
control. 

The inference engine in a knowledge based system uses information presented in 
the knowledge base to infer conclusions. The inference engine interprets the rules in 
the base in conjunction with the control options in order to infer solutions to 
consultations. There are two main ways in which inference engines control the use of 
knowledge in solving problems. In the 'data-driven' method the inference engine 
examines the data that is available and applies all the rules which are satisfied to derive 
the new data. The conclusions which are made contribute to the body of data and 
may in turn allow other rules to operate. This cycle may be repeated many times until 
eventually, a definite diagnosis is reached or a recommendation is concluded. The 
second method, the 'goal-driven' approach begins at the opposite end of the logical 
process. The goal-driven approach identifies the conclusions that it needs to establish 
its goals, and then examines the rules to see w T hich ones contribute to these goals. The 
next step is to look at the "If. . . " part of the "If. . . Then" rules and locate any missing 
data that may be needed to reach the conclusions. Missing data is then filled in as new 
'subgoals' or through an interactive process with the user. As w r ith the data-driven 
method, the cycle may be repeated many times, and it may require many generations of 
subgoals before the expert system is able to obtain all the necessary data to achieve its 
goals. If the facts and rules are sufficiently comprehensive, and they contain all the 
information that is logically required to make a decision, then all the inference engine 
has to do is make sure all the relevant facts and rules are retrieved at the same time. If 
the facts and rules are not sufficiently comprehensive then the inference engine will be 
unable to make conclusions based on the facts presented. The power of an expert 
system comes from the quality and comprehensiveness of the knowledge base not from 
sophisticated features of the system. [Ref. 9: p. 131] The details and construction of an 
expert system vary enormously from design to design, albeit, the idea of knowledge is 
always central. 

G. STEPS IN CONSTRUCTING AN EXPERT SYSTEM 

In constructing an expert system the goal is to replicate expert decision making 
with the aid of a computer. In order to accomplish this requires a well planned and 
flexible design strategy. The phases involved in constructing an expert system are: 

1. Determine if a task is suited to expert system technology 

2. Knowledge acquisition 
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3. Implementation Stage 

4. Initial system design 

5 . Building a prototype system 

6. Analysis and redesign 

7. Final analysis and fine tuning 

8. System maintenance 

1 . Determining if a task is suited to expert system technology 

One of the major reasons for the development of expert systems was for 
applications and solutions to problems with situations where a programming algorithm 
would not be practical. An analysis of the task to be performed should be 
accomplished to. ensure that the expert systems approach is the best and most practical 
way to address the problem, or perhaps the problem is best suited for some other type 
of programming technique. 

There are several characteristics that are commonly associated with the use of 
expert system technology: 

• Tasks which involve knowledge that can be expressed as "rules of thumb" 

• Problems which human experts typically perform 

• Tasks which involve knowledge that is rapidly changing 

• Tasks which do not rely heavily on "common sense" 

• Tasks which involve inexact reasoning 

• Tasks that can be represented as a set of independent actions or conditions 
These tasks represent areas that might be useful for the application of expert system 
technology. 

2. Knowledge acquisition 

This next phase involves the gathering of information and formalization of 
data that will be necessary to develop an expert system, this includes the identification 
of all the parameters, including participants, problem characteristics, resources and 
goals, which are associated with tasks or problems under consideration. From the 
acquisition and analysis of knowledge comes the entire development strategy of how 
the follow-on phases will be carried out. During this phase the major components of 
the reasoning process and identification of the elements that should be included in the 
expert system are determined. 

Refinement of the acquired knowledge and organization of key elements has 
to be accomplished before any further system development. The analysis of the 
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knowledge and elements should be according to the interrelationships between the 
elements. Instances where two or more reasoning paths make use of the same 
information, and identification of how these reasoning paths are related should be 
noted and identified. This will allow the developers of the expert system to continually 
refine the knowledge acquired and help eliminate unnecessary or redundant 
information. The concepts and relations that are identified in the first phase are made 
explicit during this phase. Questions such as: What type of data is available?, What is 
given and inferred?, and, What processes and constraints are involved in the problem 
solution?, are asked by the knowledge engineer to the source of his knowledge. There 
has to be repeated interactions between the knowledge engineer and the expert source 
in order to develop key concepts and relations. 

3. Implementation Stage 

Implementation involves the mapping of the formalized knowledge into the 
represented framework associated with the tools to solve the problem. As the 
knowledge in this framework is made compatible, consistent and organized, the 
framework becomes an executable program. The knowledge engineer then evolves a 
useful representation for the knowledge collected and will use it to develop a prototype 
expert system. The development of the prototype system is an extremely important 
step in the construction of an expert system. The prototype knowledge base is 
implemented by using w-hatever knowledge engineering aids available and chosen for 
development of the program. The formalization involves mapping the key concepts, 
subproblems and information flow characteristics that have been isolated during the 
knowledge acquisition phase, into formal representations based upon knowledge 
engineering tools or frameworks. There are two important factors during this stage: 
the underlying model of the process and the characteristics of the data. Formalization 
of these two factors with the conceptual information flow and the subproblem elements 
organizes the framework and the sketch of the concepts and relations inherent in the 
problem to be solved. 

4. Initial svstem design 

This next phase involves the organization of information acquired during the 
knowledge acquisition phase and modelled in the implementation stage, into a form 
that will be usable by the expert system. The overall purpose of this expert system 
should be kept in mind when designing the system. The design should reflect the most 
efficient manner in which to represent the acquired knowledge and should also provide 



21 



a user interface that will be appropriate for users of the system who may not fully 
understand expert systems. In system design, representation of the knowledge needs to 
be understood, and a determination needs to be made as to the best way to represent 
the knowledge that will be used by the system. The expert system makes use of a 
taxonomy file and a rule base file to store the knowledge that has been acquired and 
refined by the experts. 

5. Building a prototype system 

After the initial system design has been finalized, the next phase is to build a 
prototype of the expert system. This phase incorporates the following steps: 

1. The initial taxonomy and rules are constructed 

2. Production of an interpreter that incorporates the elements of the taxonomy 

3: Validity of the taxonomy and rule base is tested through the use of expert 

system predicates 

The development of the prototype system should be accomplished 
incrementally. Limited versions of the rule base file and the taxonomy file should be 
coded and tested. After these initial rules and taxonomies have been tested then 
further construction of these two files can be accomplished and incorporated with the 
original files. The finished prototype should be a complete working system, and from 
this prototype the expert should be able to determine if the system is performing as an 
expert would when presented with the circumstances and problems. 

6. Analysis and redesign 

The prototype system that has been developed should be tested extensively by 
the experts who acquired the knowledge during the acquisition phase. Then during this 
phase the experts can determine if the conclusions reached by the expert system are in 
fact valid and are answers that an expert would make from the situations being tested. 
The prototype system should be first tested with a couple of examples from start to 
finish. These examples should be of a magnitude that they determine the weaknesses 
of the system, knowledge base, and inference structure. The elements that normally 
cause poor performance are input/output characteristics, control strategies, inference 
rules, and the test examples used on the system. At this point any changes can be 
recommended and redesign of the system may be in order. Through this analysis and 
redesign phase, areas may be discovered by the experts w’here there needs to be further 
explanation given for the actions taken by the system in reaching a conclusion. The 
search paths used and reported by the expert system should be checked to ensure that 



they are reasonable, valid, and the correct path to take. Through this analysis process, 
any changes that need to be made by the expert system can be identified. Once 
analysis of the system has been completed, the redesign of the system can begin, and 
the designers can continue to build and improve the system prototype based upon the 
findings made during the analysis. 

7. Final analysis and fine tuning 

After the initial analysis has been accomplished and the recommended changes 
have been incorporated into the initial design, the system should be ready for final 
testing. The individuals who tested the initial system should also test the revised 
system. 

8. System Maintenance 

Expert systems are often used for tasks in which the input information may 
have to be changed, updated* or revised. Whenever this occurs, the system may need 
to be analyzed and tested to see if the conclusions generated by the expert system are 
still valid and best for the situation. The updating and additional system development 
should be accomplished by those persons who did the knowledge acquisition, in order 
to maintain system organization and systematic programming. 

Attempting to replicate expert . decision-making with a computer requires a 
well and carefully planned yet flexible design strategy. Construction of an expert 
system from the initial design to a working system consists of following the above 
loosely defined steps. Because the programming task of an expert system often 
includes a complex interrelationship between elements of the system, the design of an 
expert system may require many reworkings before an accepted performance level is 
achieved. 

H. SUMMARY 

Expert systems investigate methods and techniques for the construction of man- 
machine systems that have a specialized decision-making expertise. Expertise consists 
of knowledge about a particular domain, understanding of a domain problem, and 
skills at solving the problem. The formulation of knowledge in an expert system is 
accomplished by the knowledge engineer who gathers knowledge from public and 
private sources on a particular subject. This knowledge is then used to develop the 
basic concepts to be used in an expert system. Identification of relationships that exist 
between the basic concepts leads to the formulation of a rule base. The construction 
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of an expert system prototype then enables the expert to evaluate rule base design and 
system execution. Final development of a full-scale system requires extensive analysis, 
redesign and testing. 



III. DEVELOPMENT OF 'EXPERTAIR' 



A. OVERVIEW 

The primary goal of this thesis was to investigate the feasibility of applying an 
expert systems approach to non-repetitive problems in a stochastic environment. It 
was hoped that a set of rules could be established for a deterministic sequence of 
events and later adapted to the non-repetitive problem. A determination was made to 
utilize a military problem as a testbed for an expert system construction and 
evaluation. The air defense weapons employment process was to be modelled within 
specified parameters and subsequently evaluated using an expert system prototype. 
The choice of developing a model supporting military decision-making in an air defense 
milieu was based upon the author's combined background in tactical computers and 
operational experience in the air defense field. It was hoped that through the 
development of the model,' a better understanding could be obtained on the 
complexities and requirements of the air defense/battle management process. In 
addition, it was desired that a^ prototype expert system could be developed for use as a 
framework for training devices in the air defense field. 

The methodology that was used to accomplish the research paralleled the first six 
steps for construction of an expert system outlined in Chapter II. During the initial 
problem analysis, the weapons employment process was found to be a candidate 
problem for expert systems technology. The knowledge acquisition phase produced an 
initial bounding of the environment, identification of resources, and anticipated goals 
for tactical system employment. The implementation stage consisted of brainstorming 
various concepts to represent the pertinent information. These concepts were then 
organized into a hierarchical structure in order to identify conceptual information flow. 
In the initial system design, a model framework was developed to specify the direct and 
indirect relationships of all key concepts. An expert system development package was 
then utilized to organize the model framework into the working prototype 
'EXPERTAIR'. The final stage of the system development included the construction 
of formatted system data files which were used to evaluate the operability of the 
prototype expert system. 
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Construction of 'EXPERTAIR', from initial design to working prototype, 
consisted of extensive programming to develop the concepts and concept relationships 
that existed within the weapons employment process model. The design of 
'EXPERTAIR' required many reworkings before operability was achieved. Although 
outside evaluators were not utilized to conduct a detailed analysis of 'EXPERTAIR', it 
was determined by the authors of this thesis that the prototype was able to infer 
accurate conclusions from the input data files. 

B. INTRODUCTION 

Active air defense may be defined as direct defensive action taken to destroy or 
reduce the effectiveness of an enemy air attack. Passive air defense includes measures 
taken to minimize the effects of hostile air action and includes cover, concealment, and 
dispersion. [Ref. 10: p.9.2-5] The U.S. Marine Corps air defense mission, operationally 
executed by a Tactical Air Operations Center (TAOC), may be categorized into three 
specific tasks: area surveillance, enroute traffic control, and weapon systems 

employment. The task of area surveillance includes the detection, identification, and 
classification of acquired targets within an area of responsibility. Surveillance is 
primarily accomplished utilizing the TAOC's internal sensors capabilities but is 
routinely supplemented by external sources via data link. A summary display of the air 
situation is maintained and appropriate information is disseminated to other agencies. 
Enroute traffic control is also normally an internal function of the TAOC consisting of 
flight advisory, direction, monitoring, and control of itinerant aircraft. Flight plans are 
received and correlated with radar contacts for positive identification. Positive control 
is provided to launching and recovering aircraft. The third task of the air defense 
mission requires a direct interface with external agencies. The employment of air 
defense assets in the defense of a designated vital area is the intrinsic mission of a 
TAOC. This task integrates with the other functions of the TAOC in order to appraise 
the danger of an airborne threat and determine the appropriate action required to 
neutralize it. 

There exists a multitude of weapon platforms in the U.S. military arsenal that are 
capable of supporting the air defense mission. Currently, that Marine Corps mission is 
sustained by (1) the F/A-18 and F-4 fighter aircraft, long range airborne weapon 
systems, (2) the IHAWK surface-to-air missile system, an intermediate range ground 
platform, and (3) the redeye/ stinger surface-to-air missile system, a hand-held, short 
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range weapon. The integration of these assets into a coordinated air defense system 
requires an extensive understanding of the characteristics of the weapon platforms and 
a knowledge of their tactical employment. 

The decision to direct a particular weapon system against a potential threat is 
made by the Senior Weapons Director within the TAOC. This decision-making 
process requires the consideration of vast amounts of data in order to ensure a proper 
response. The current environment in which air defense assets may be employed has 
reduced the amount of time available in which to make a decision. 

C. PROBLEM STATEMENT 

The present requirement to analyze input information and formulate an 
expedient and appropriate decision under adverse conditions has severely challenged 
the air defense community. Current algorithmic computer devices that support the 
weapons employment process are inflexible and provide only limited data analysis. 
Total automation of the air defense mission might be a distant solution, however, a 
man-in-the-loop, real-time decision aid may provide near-term assistance. In an 
attempt to apply expert systems technology to the air defense problem, this chapter 
seeks to answer the following questions: 

1. Can the air defense weapons employment process be modelled? 

2. Can an expert svstem prototype be developed to aid and support the air defense 
decision-making' process? 

Without an ability to rapidly process large amounts of information and examine all 
available options, the decision-maker may be forced to make less than optimum 
decisions during time of war. 

D. MODEL 

The air defense Weapons employment process entails a series of data input, 
evaluations, actions, and changes that are designed to bring about a desired result. 
Since the weapons employment process is utilized in a stochastic environment, a 
multitude of variables are present making it difficult to assess relationships that exist 
between the data input and the resultant actions. In order to define the weapons 
employment process for subsequent analysis, a unique representation or model of the 
process will be developed using specified parameters. Development of this model will 
allow for the establishment of a set of rules which provide deterministic conclusions to 
a given problem. 
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E. ENVIRONMENT 



In order to model the air defense weapons employment process, a thorough 
analysis had to be made on the environment in which the process would be utilized. A 
description of all the parameters which may affect the process w'ould be almost 
impossible, however, an initial list w'as defined which could be later modified if model 
expansion w r as desired. This bounding of the environment w r as accomplished for our 
model by determining a mission statement and identifying the air defense assets 
available to the TAOC. For our model, the TAOC was tasked to provide a limited 
point air defense capability for a designated vital area against a small to moderate 
projected threat. A secondary mission included the protection of all air defense 
resources. The assets available included a limited squadron of fighter aircraft (total of 
nine), an automated TAOC with multiple sensors, an IHAWK battery with 12 
available missiles, and a platoon of redeye/stinger personnel with 20 available missiles. 

The stipulation of a maximum number of available assets (aircraft/missiles) was 
important in the model development. It was felt that this real world limitation directly 
impacts the decision-making process. In order to calculate the best response to an 
enemy's action, the Senior Weapons Director in the TAOC must identify the 
operational availability of all weapon systems, determine the options available to 
neutralize the threat, and project future demands on assets. For our model, the final 
action taken to negate a threat would be partially contingent upon limited assets 
without anticipated resupply. 

Intelligence on the enemy is another real world facet of the decision-making 
process. Accurate and timely information on the enemy, including type, size, and 
intentions, increases the probability of predicting the best response to an enemy action. 
For our model, generic parameters such as fighter aircraft speed and HAWK missile 
maximum kill ranges were utilized in the specification of enemy and friendly 
capabilities in order to allow the thesis classification to remain UNCLASSIFIED. 
However, in order to fully implement a tactical air defense decision aid, it would be 
necessary to develop a knowledge base founded upon actual systems parameters. 

Information contained in an air defense mission directive usually includes a 
specified surveillance sector or Area of Responsibility (AOR). The determination of a 
TAOC's AOR, whether 40° or a full 360° sector, will assist in the development of a 
sensor emplacement and tactical utilization plan. An objective of this plan is to ensure 
maximum area coverage while minimizing transmissions in the electromagnetic 
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spectrum by radiating only in the required sector. For our model, an AOR subtending 
the arch from 000°, or North, to 140° or Southeast was directed. 

F. WEAPON SYSTEMS EMPLOYMENT 

After the establishment of the AOR, the next task to be accomplished in the 
model development was the determination of the optimum location for weapon systems 
employment. Important factors in this determination included weapon systems 
capabilities, support limitations, surveillance and communications restrictions, and 
enemy characteristics. These variable factors affect the weapons employment process 
in an operational TAOC and should be considered. For our model, all air defense 
assets were located at the center of the vital area (area to be protected). 

In the development of an air defense plan, the Senior Weapons Director analyzes 
available weapon systems capabilities to help determine the boundaries of a designated 
destruction area. The destruction area is an area in which the enemy will be destroyed 
or defeated. It is divided into a missile intercept zone, cross-over zone, and air 
intercept zone. The destruction area begins at the edge of the vital area. Its size varies 
with the capabilities of the air defense system, the engagement sequence, and the 
surveillance capabilities. The missile intercept zone (MIZ) identifies the area where 
tracking solutions and engagement sequences from surface-to-air missile units will 
occur. This zone may be determined by ground missile system maximum kill ranges, 
terrain limitations, and weather. The crossover zone is a buffer area and identifies a 
region where airborne platforms should start to discontinue target intercepts and allow 
the ground-based systems to begin target tracking. The region beyond the crossover 
zone and bounded by the AOR is designated as the air intercept zone (AIZ) and 
constitutes the area of airborne target engagement. 

A determination must be made on the location, number, and composition of 
fighter holding positions or Combat Air Patrol (CAP) stations that are required to 
protect the vital area. The kill probability required for air defense has the greatest 
influence on CAP employment. Other real world factors which influence the stationing 
of CAP'S are: [Ref. 11: p. 161] 

1. The required probability of detection. 

2. The capability of surface radar to achieve this probability of detection. 

3. The effective kill probabilities of secondary, defensive surface-to-air missile 
systems. 

4. Size and orientation of AOR. 

5. The number of fighter aircraft available. 
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Examination of these factors led to the determination of the model's optimum CAP 
station locations. This data, along with AOR specifications, asset locations, and 
designation of the destruction area, has been depicted on a tactical working area map 
in Figure 3.1. This map can be utilized when briefing the environment of the weapon 
systems employment process. The locations of the CAP stations are denoted by a 
bearing and range from system center (the TAOC's location). 
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The development of the tactical working area map completed the analysis and 
identification of the environment. The air defense role and the system requirements 
were defined and bounded. The next step used in the knowledge acquisition process 
dealt with the identification and formalization of concepts used to represent the given 
knowledge. 

G. KNOWLEDGE CONCEPTS 

In order to model a large-scale system such as the air defense weapons 
employment process, it was necessary to define the separate components that aggregate 
into the system as a whole. Decomposition of the system into individual elements 
allowed for a more precise definition of the specific system structure. In the 
development of the model, the weapons employment process was envisioned to consist 
of six abstract ideas or concepts. These interactive concepts were designated system 
status information, target, fighter, airborne, and probability of intercept information, 
and specific actions available to neutralize a threat. The concepts were then further 
broken down into properties and roles in an attempt to relate them to specific data 
items that currently existed or could be obtained through present air defense 
mechanisms. A property is a quality of a concept while a role is a component of a 
concept. A role usually specifies a value or a number restriction or constraint. 

The system status concept included information on the current state of alert, the 
weapons condition as basis for rules of engagement, and the status of the individual air 
defense assets. The limitations on available assets were defined here. This information 
could be compiled utilizing the internal TAOC command structure along with 
communication links to the external agencies. 

The concepts of target and fighter contained data developed within the TAOC. 
Most of this information could be automatically obtained or operator entered utilizing 
present TAOC equipment. The target roles included identity, location, speed and 
movement of target aircraft while the fighter roles identify status, location, and 
targeting information of fighters. Both concepts only allowed input from two separate 
aircraft or groups of aircraft, thus leading to identical restrictions on targets #1 & #2 
and fighters #1 & #2. A maximum of two fighter sections versus two target groups 
could be analyzed during a single data input. These limiting factors were introduced to 
restrict the number of rules required to substantiate the model. However, the 
expansion of this concept could be easily achieved to support larger numbers of aircraft 
by using similar rules applicable to the single aircraft. 
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The airborne concept described the number of targets and fighters that were 
airborne at data input. This concept limited duplications of information queries within 
the rule file by condensing the number of data items applicable to a rule. 

The probability of intercept (POI) concept consisted of applicable system status, 
target, and fighter data input, and described an intercept probability for the airborne 
fighters. This concept was also limited to information on a maximum of two fighter 
and target groups. The concept parameters described the intercept probabilities for 
fighter #1 versus target #1, fighter #2 versus target #1, etc. The probability categories 
ranged from zero to low, medium, and high POI's. These categories corresponded to a 
fighter's ability to cover or engage a specified target. A high POI corresponded to a 
80-100% probability of intercepting a target and maneuvering to a position from which 
to commit on a target. A medium POI : 50-79%; low POI : 1-49%; zero POI : 0%.. 

The final knowledge concept of neutralizing actions consisted of the various 
actions that could be taken to neutralize a potential threat. These actions paralleled 
the decisions that a Senior Weapons Director would be required to make in a tactical 
situation. The final actions ranged from continuing normal surveillance to engagement 
of target #2 with fighter #1 while fighter #2 engages with target #1 or some variation. 

Recognition of the relationships that exist between the concepts and 
determination of the data structure completed the modelling . of the weapons 
employment process. The model shown in Figure 3.2 represents an input of data, 
obtained from a specified air defense environment, that is distributed to applicable 
concepts. The final concept, which directs an appropriate weapons employment 
action, is an input to the entire process and indicates continuous flow of information. 

H. THE 'EXPERTAIR' PROTOTYPE 

Having a structured understanding of the air defense weapons employment 
process, an attempt was made to apply an expert systems approach toward the 
development of a decision support aid for that military problem. A prototype, 
designated 'EXPERTAIR', was developed to simulate the functionings of an expert 
system operating in a tactical environment utilizing existing Marine Corps air defense 
equipment for data input. The prototype was evaluated for operability and was found 
to be simple to operate, user friendly, and provide concise expert conclusions based 
upon the current situation. A detailed analysis of 'EXPERTAIR' was beyond the 
scope of this thesis, however, the conclusions produced by the expert system prototype 
were identified by the authors as accurate and appropriate. 
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Sensors 




Figure 3.2 Conceptual Model of Weapons Employment Process. 

During the initial design of EXPERTAIR', the concepts that were identified in 
the weapons employment process model were coniigured into an expert system format 
using the Arityi Expert Development Shell as a development tool. The Arity shell met 
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the desired implementation criteria of uncomplicated, user friendly software coding 
format and instructions. In addition, it provided a large capability to evaluate and 
expand system performance. Arity software may be executed utilizing a standard 
personal computer with 610K of memory. 

The development of 'EXPERTAIR' entailed the construction of various software 
files that conformed to a structured Arity format. Implementation of the completed 
'EXPERTAIR' prototype required the execution of the Arity! Expert Development Shell 
software in conjunction with the formatted files. The structure of 'EXPERTAIR', 
depicted in Figure 3.3, displays the different files that formed the final prototype. The 
following discussion reviews the content of the files while the actual file listings are 
found in Appendixes A through F. A software dictionary is presented in Appendix G 
which defines some of the terms used the 'EXPERTAIR' files. 

1. Front-End File 

A front-end file contains the code that controls the execution of the developed 
expert system. The contents of the 'EXPERTAIR' front-end file (Appendix A), w r ritten 
in Prolog, specify the procedures for execution of the database files and the format of 
the user's terminal screen display. In addition, the execution of the 'EXPERTAIR' 
conversion program (Appendix B) is controlled by the front-end file. Also written in 
prolog, the- conversion program converts a DBASE III Plus file into a Prolog file which 
can then be evaluated by the system. 

2. Taxonomy File 

A taxonomy is a structured representation of the general information used in 
an expert system. The basic purpose of the taxonomy language is for defining the 
concepts that are used in a developed expert system. The taxonomy language defines 
these concepts in a form that can be interpreted by the computer. The strategy used 
for constructing a taxonomy file involves the mapping of relationships of the identified 
concepts. Every element that is involved in the decision process must be identified and 
defined in the taxonomy file. From this point, elements to be described in the 
taxonomy need to be described in terms of taxonomy definitions. 

A taxonomy file has within it two distinct sets of information: type 

declarations and concept definitions. Type declarations are declarations of all 
properties and roles used in a taxonomy. Concept definitions contain the identification 
and description of the concepts and properties or roles they may have. The amount of 
information conveyed in a concept definition may have a wide variance. All concept 
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Figure 3.3 EXPERTAIR Structure. 

definitions are based on a simple taxonomy language format, although they may also 
be quite complex. 

An example concept definition from the 'EXPERIAIR taxonomy file is 
shown below: 

define primitive status with 

defcon = Iwhitc.vellow.red] and 
wepcon = [tight, Tree] and 
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runw stat = [op.nonop] and 
acft_avail = (0,y) and 
taoc stat = [op, deg, nonop] and 
hawk_stat = [op, deg, nonop, assign] and 
hawk msl = (0,15) and 
sting_msl = (0,24). 

This example depicts the description of the system status concept using the taxonomy 
language. The roles of the concept (defcon, wepcon, runw_stat, etc.) are listed along 
with the value and number restrictions of each of the roles. Definitions for the 
concepts and roles utilized in 'EXPERT AIR' can be found in Appendix G while the 
entire taxonomy file is listed in Appendix C. 

3. The Rule Base File 

The rule base file consists of a number of control options, rules and 
synonyms. Rules describe the interaction of the concepts defined in the taxonomy file. 
Through the evaluation of these rules, the expert system is able to conclude a solution 
based upon the problem put forth. A rule is composed of an antecedent and a 
consequent which establish goals between concepts. A goal is a condition that can be 
proved either true or not true. The consequent of a rule is determined to be true if 
each of the goals in the antecedent are determined by the expert system to be true. 
Consequently, if any of the goals in the antecedent cannot be shown to be true then 
the rule will fail. The consequent of a rule will always be a single goal and will always 
be listed before the antecedent. The antecedent of a rule can be one or more goals. A 
keyword if is used to separate the consequent from the antecedent, and the keyword 
and is used to separate each of the goals in the antecedent. 

Synonyms defined in the rule base file must be different from the name of any 
other concept described in the taxonomy file. Albeit, the synonym may be the same 
name as the rule it describes. The synonym definitions must appear before the use of 
the synonym in a rule. Control options used in the rule base file allow for the 
modification of the features used in the expert system in order to customize the way 
the system runs. 

Specific considerations that affect a rule base development include: 

• Analysis of rule base order 

• Relationship of rule base size to execution time 

• Consequence of multiple goals 

• Consequence of omitted rules 

• Consequence of insufficient data input 
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The order in which the rules are specified and the size of the rule base may make a 
significant difference in total system execution time (time to reach a decision). In 
addition, the omission of rules or addition of multiple goals to satisfy a single rule may 
affect the versatility and efficiency of an expert system. The problem of insufficient or 
incorrect data input should also be taken into account. In an environment in which 
time is of critical importance, an attempt should be made to optimize the rule base 
structure through detailed testing and evaluation. 

The objective of 'EXPERTAIR's rule base development was to identify the 
interactions between the concepts listed in the taxonomy file. The rule base w r as not 
envisioned to be exhaustive but rather thorough in covering a wide range of 
conceivable air defense situations. An example from the 'EXPERTAIR' rule base is 
shown below: 

the neutr action of airdefense is ewhl 
if~ 

the hawk_stat of svstem_status_jnfo is fop.deg] and 
the hawk msl of svstem status info is X and~ 

X"> 0 and 

the tarl_class of target_info is hostile and 
the airborne_tar of airborne info is one and 
the airborne fit of airbomejinfo is one and 
' the probl l_intercept of intercept_info is zero. 

In this example, the consequent of the rule is the decision to neutralize a single target 
(threat) with a HAWK missile. The antecedent of the rule is made up of the following 
conditions: (1) The HAWK missile system must be operational or degraded, (2) At 
least one HAWK missile must be available, (3) The target must be classified 
HOSTILE, (4) Only one target is airborne, (5) Only one fighter is airborne, and (6) 
The probability of the airborne fighter intercepting (and destroying) the target is zero. 
If all six conditions of this rule are found to be true, then the consequent of the rule is 
also true. A complete listing of 'EXPERTAIR's rule base is given in Appendix D. 

4. Calculation File 

The calculation file determines the value of a goal which has been presented in 
the rule base file. Although not required for expert system execution, the calculation 
file is utilized to reduce execution time by continuously calculating and updating goal 
values. If the calculation file were not used, the goal values for each rule in the rule 
base would have to be individually calculated, usually causing duplication of effort. 

Using the rule base example cited above, the 'EXPERTAIR' calculation file 
continuously identifies, calculates, and updates at data input all values for expert 
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system evaluation to include the HAWK missile system status, the number of missiles 
available, the classification of the airborne target, etc. These values are then available 
for all rules identified in the rule base. The calculation file that was developed for 
'EXPERTAIR' is found in Appendix E. 

5. Database File 

Database files were constructed for 'EXPERTAIR' as a means of simulating 
data input to our prototype. Written in Prolog, these files, excluding Database XPT1 
(file #1), were internal to the 'EXPERTAIR' prototype and were utilized as a means of 
testing system operability. The files are representative of actual data that could be 
derived in an air defense conflict. The majority of the data necessary to provide input 
to our prototype is presently generated in a TAOC, however, the hardware that would 
be required to interface with a decision support expert system does not exist. 

The second objective of our thesis was to examine the feasibility of interfacing 
an expert system prototype with an outside system. Accomplishment of this objective 
would give more credibility to the near-term implementation of an expert system. 
'EXPERTAIR' was developed with a capability to accept data input from outside the 
existing prototype, evaluate the data, and provide an expert decision. This function 
was tested using Database XPT1, a database file written in DBASE III Plus, and vis-a- 
vis the conversion file, it was translated into a prolog file for use by our prototype. All 
database files used in testing 'EXPERTAIR' are described in the next chapter while the 
actual file listings are given in Appendix F. 

I. SUMMARY 

The application of an expert systems approach to non-repetitive problems in a 
stochastic environment may have relevance to certain military tasks. The 
establishment of a set of rules based upon a deterministic sequence of events may 
provide a means for solutions to a non-repetitive problem. The modelling of the air 
defense weapons employment process provided a framework for the development of an 
expert system prototype 'EXPERTAIR'. The model development was achieved 
through a bounding of the operating environment and identification of concepts used 
to represent the weapons employment process. Concept relationships were then 
identified and expressed in a rule base file. 'EXPERTAIR' is comprised of software 
files,, including the rule base file, which dictate date interpretation, expert system 
execution, and the user's screen presentation. The files were constructed in a specific 
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format using an expert system development package. The prototype was evaluated for 
operability using sample data files for input and was found to produce accurate 
conclusions based on a given scenario. 
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IV. EXECUTION OF 'EXPERTAIR' 



A. OVERVIEW 

An evaluation of the system operability of 'EXPERTAIR' was accomplished 
utilizing a sample scenario. Examples representative of an actual air defense 
environment were constructed in the form of database files. These files provided a 
comprehensive array of situations, within the limitations of the weapons employment 
process model, in which an air defense decision support system might be tasked to 
operate. Consideration was given to the environment in which our prototype may be 
utilized. A TAOC is updated with tactical information every six to ten seconds 
depending upon the rotation speed of the sensors (radars). Additionally, other 
information is made available through intelligence networks and communications with 
other agencies. An expert system, ideally, would be able to accept, process, and 
provide a recommendation (decision) for each new data update. A stagnant or low 
intensity conflict in which data remained constant may result in repetitious 
recommendations such as 'do nothing' or 'continue normal surveillance activities'.- 
However, a high intensity conflict would require an analysis of every accessible batch 
of data input in order to keep up with a rapidly changing environment. A critical 
decision to be made should be based upon the most current information available to a 
system. 

The execution of 'EXPERTAIR' consisted of evaluating the fifteen database files 
outlined in Appendix F. These files consisted of individual snap-shot situations along 
with sequences of events (3-4 files). Each file was processed, developing individual 
conclusions to the data input. The current data input was initially displayed on a 
monitor screen while the information was being processed. At the completion of the 
data processing, the expert system conclusions were displayed under the screen heading 
'Recommendation'. 

The remainder of this chapter depicts the results of the execution of 
'EXPERTAIR' to include data input, screen display, and recommendations for the 
fifteen files. Each file is introduced with a background on the current tactical situation 
prior to making a decision. One capability that is characteristic of expert systems is 
the ability to obtain explanations on all intermediate and final decisions. An example 
of this capability is given at the conclusion of this chapter. 
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B. EXECUTION LISTINGS 

File Number (1): This File was constructed utilizing DBASE III Plus and 
converted into a useable system format. It represents a low threat environment. 
Situation is calm. TAOC has identified no targets in the AOR. All Fighters are on the 
runway. All assets are Fully operational. 



CURRENT AAW STATUS 



Defense Condition: 


White 


Weapon Condition: 


Tight 


Runway Status: 


OP 


Avail Fighter AC: 


9 


TAOC Status: 


OP 


Hawk Status: 


OP 


Hawk. Missile Inv: 


12 


Stinger Msl Inventory: 


20 




TARGET INFORMATION 




Track Number (1): 


0 


Track Number (2): 


0 


Bearing: 


0 


Bearing: 


0 


Range: . 


0 


Range: 


0 


Size: 


0 


Size: 


0 


Speed: 


0 


Speed: 


0 


Class: 


Unknown 


Class: 


Unknown 


Movement: 


Unknown 


Movement: 


Unknown 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (2): 


Fullop 


Fit Size: 


1 


Fit Size: 


1 


Location: 


Onrun 


Location: 


Onrun 


Avail Msls: 


6 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


0 


Assigned to TN: 


0 


Assigned to TN: 


0 


RECOMMENDATION: 


Continue 


normal surveillance; no 


immediate threat 



present; no decision is required. 
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File Number (2): New File. Also a low threat environment. The TAOC has 
identified a target in the area and has determined it to be a probable (assumed) friend. 





CURRENT AAW STATUS 




Defense Condition: 


White 


Weapon Condition: 


Tight 


Runway Status: 


Op 


Avail Fighter AC: 


9 


TAOC Status: 


Op 


Hawk Status: 


Op 


Hawk Missile Inv: 


12 


Stinger Msl Inventory: 


20 




TARGET INFORMATION 




Track Number (1): 


4001 


Track'Number (2): 


0 


Bearing: 


135 


Bearing: 


0 


Range: 


200 


Range: 


0 


Size: 


1 


Size: 


0 


Speed: 


350 


Speed: 


0 


Class: 


Asfriend 


Class: 


Unknown 


Movement: 


Closing 


Movement: 


Unknown 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (2): 


Fullop 


Fit Size: 


1 


Fit Size: 


1 


Location: 


Onrun 


Location: 


Onrun 


Avail Msls: 


6 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


0 


Assigned to TN: 


0 


Assigned to TN: 


0 


RECOMMENDATION: 


Continue 


normal surveillance; no 


immediate threat 



present; no decision is required. 
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File Number (3): New file. A single target has been detected in the area. The 
TAOC has classified the target as a probable (assumed) enemy. There are no other 
aircraft airborne. 





CURRENT AAW STATUS 




Defense Condition: 


White 


Weapon Condition: 


Tight 


Runway Status: 


Op 


Avail Fighter AC: 


9 


TAOC Status: 


Op 


Hawk Status: 


Op 


Hawk Missile Inv: 


12 


Stinger Msl Inventory: 


20 




TARGET INFORMATION 




Track Number (1): 


4002 


Track Number (2): 


0 


Bearing: 


no 


Bearing: 


0 


Range: 


185 


Range: 


0 


Size: 


1 


Size: 


0 


Speed: 


375 


Speed: 


0 


Class: 


Asenemy 


Class: • 


Unknown 


Movement: 


Orbiting 


Movement: 


Unknown 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (1): 


Fullop 


Fit Size: 


1 


Fit Size: 


1 


Location: 


Onrun 


Location: 


Onrun 


Avail Msls: 


6 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


0 


Assigned to TN: 


0 


Assigned to TN: 


0 


RECOMMENDATION: 


Launch 


Fighter #1 and assign to 


Cap C. Attempt 



determine intentions of target. If target is identified as a threat, set Defense Condition 
to yellow. 
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File Number (4): Continuation file. Defense condition has been increased to 
yellow. A single fighter has been launched and is holding at CAP 'C. The TAOC has 
identified and classified a second section of targets in the area. Both targets are not 
considered high priority targets due to their movement (orbiting). 

CURRENT AAW STATUS 



Defense Condition: 


Yellow 


Weapon Condition: 


Tight 


Runway Status: 


OP 


Avail Fighter AC: 


9 


TAOC Status: 


OP 


Hawk Status: 


OP 


Hawk Missile Inv: 


12 


Stinger Msl Inventory: 


20 




TARGET INFORMATION 




Track Number (1): 


4002 


Track Number (2): 


4003 


Bearing: 


110 


Bearing: 


028 


Range: 


185 


Range: 


170 


Size: 


1 


Size: 


2 


Speed: 


375 


Speed: 


400 


Class: 


Asenemy 


Class: 


Asenemy 


Movement: 


Orbiting 


Movement: 


Orbiting 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (2): 


Fullop 


Fit Size: 


1 


Fit Size: 


1 


Location: 


CCap 


Location: • 


Onrun 


Avail Msls: 


6 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


0 


Assigned to TN: 


0 


Assigned to TN: 


0 



RECOMMENDATION: Continue surveillance of target/s. Launch (as required) to 
position fighters at CAPS's A & B. If a hostile act is commited, then engage target. 
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File Number (5): Continuation file. Single fighters are located at CAP's 'A' and 
B'. The single target has become a greater threat due to decreasing range to the vital 



area. No hostile act has yet been committed. 






CURRENT AAW STATUS 




Defense Condition: 


Yellow 


Weapon Condition: 


Tight 


Runway Status: 


OP 


Avail Fighter AC: 


9 


TAOC Status: 


OP 


Hawk Status: 


OP 


Hawk Missile Inv: 


12 


Stinger Msl Inventory: 


20 




TARGET INFORMATION 




Track Number (1): 


4002 


Track Number (2): 


4003 


Bearing: 


110 


Bearing: 


030 


Range: 


170 


Range: 


190 


Size: 


1 


Size: 


2 


Speed: 


425 


Speed: 


400 


Class: 


Asenemy 


Class: 


Asenemy 


Movement: 


Inbound 


Movement: 


Outbound 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (2): 


Fullop 


Fit Size: 


1 


Fit Size: 


1 


Location: 


ACAP 


Location: 


BCAP 


Avail Msls: 


6 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


0 


Assigned to TN: 


' 0 


Assigned to TN: 


0 



RECOMMENDATION: Cover threat (target 1) with fighter #2 and attempt to 
determine intentions. If a hostile act is committed or if target enters the restricted 
area, then engage target. Inform HAWK and Stinger units of situation. 
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File Number (6): Continuation file. The TAOC had assigned the closest asset 
(fighter #2) to cover the inbound threat. However, the target is now indicating an 
outbound movement (simulating a feint). No other targets in the area. 





CURRENT AAW STATUS 




Defense Condition: 


Yellow 


Weapon Condition: 


Tight 


Runway Status: 


OP 


Avail Fighter AC: 


9 


TAOC Status: 


OP 


Hawk Status: 


OP 


Hawk Missile Inv: 


12 


Stinger Msl Inventory: 


20 




TARGET INFORMATION 




Track Number (1): 


4002 


Track Number (2): 


0 


Bearing: 


110 


Bearing: 


0 


Range: 


175 


Range: 


0 


Size: 


1 


Size: 


0 


Speed: 


425 


Speed: 


0 


Class: 


Asenemy 


Class: 


Unknown 


Movement: 


Outbound 


Movement: 


Unknown 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (2): 


Fullop 


Fit Size: 


1 


Fit Size: 


1 


Location: 


ACAP 


Location: 


Assign 


Avail Msls: 


6 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


65 


Assigned to TN: 


0 


Assigned to TN: 


4002 



RECOMMENDATION: Cancel cover/engage assignment. Target is no longer an 
immediate threat. Return fighters to CAP or return to base and replace as required. 
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File Number (7): New file. Single fighters located on CAPs. Two different 
targets have been detected by the TAOC. Both are possible threats due to movement. 
All assets are fully operational. A sample presentation of the the explanation facility is 
presented at the conclusion of this file. 





CURRENT AAW STATUS 




Defense Condition: 


Yellow 


Weapon Condition: 


Tight 


Runway Status: 


OP 


Avail Fighter AC: 


9 


TAOC Status: 


OP 


Hawk Status: 


OP 


Hawk Missile Inv: 


12 


Stinger Msl Inventory: 


20 




TARGET INFORMATION 




Track Number (I): 


4010 


Track Number (2): 


4012 


Bearing: 


050 


Bearing: 


130 


Range: 


190 


Range: 


175 


Size: 


1 


Size: 


1 


Speed: 


400 


Speed: 


400 


Class: 


Asenemy 


Class: 


Asenemy 


Movement: 


Inbound 


Movement: 


Inbound 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (2): 


Fullop 


Fit Size: 


1 


Fit Size: 


1 


Location: 


ACAP 


Location: 


BCAP 


Avail Msls: 


6 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


0 


Assigned to TN: 


0 


Assigned to TN: 


0 



RECOMMENDATION: Cover threat (target 1) with fighter #1 and (target 2) with 
fighter #2 and attempt to determine intentions. If a hostile act is committed or if 
target enters the restricted area, then engage target. Inform Hawk and Stinger units of 
situation. 
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File Number (8): Continuation file. The TAOC has the two fighter sections 
assigned to cover the inbound targets. Target movement remains the same. 

CURRENT AAW STATUS 



Defense Condition: 


Yellow 


Weapon Condition: 


Tight 


Runway Status: 


OP 


Avail Fighter AC: 


9 


TAOC Status: 


OP 


Hawk Status: 


OP 


Hawk Missile Inv: 


12 


Stinger Msl Inventory: 


20 




TARGET INFORMATION 




Track Number (1): 


4010 


Track Number (2): 


4012 


Bearing: 


050 


Bearing: 


128 


Range: 


180 


Range: 


165 


Size: 


1 


Size: 


1 


Speed: 


400 


Speed: 


410 


Class: 


Asenemy 


Class: 


Asenemy 


Movement: 


Inbound 


Movement: 

♦ 


Inbound 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (2): 


Fullop 


Fit Size: 


1 


Fit Size: 


1 


Location: 


Assign 


Location: 


Assign 


Avail Msls: 


6 


Avail Msls: 


6 


Range to Tar_TN: 


78 


Range to Tar_TN: 


57 


Assigned to TN: 


4010 


Assigned to TN: 


4012 



RECOMMENDATION: Continue to monitor target assignment/s. If a hostile act is 
committed, then engage target/s. Update HAWK and Stinger units. 
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File Number (9): New File. Two sections of fighters are on CAP. The TAOC 
detects a fast low flying target moving toward the vital area. Target has been classified 
hostile but is outside the range of CAP aircraft. 





CURRENT AAW STATUS 




Defense Condition: 


Yellow 


Weapon Condition: 


Tight 


Runway Status: 


OP 


Avail Fighter AC: 


9 


TAOC Status: 


OP 


Hawk Status: 


OP 


Hawk Missile Inv: 


12 


Stinger Msl Inventory: 


20 




TARGET INFORMATION 




Track Number (1): 


4020 


Track Number (2): 


0 


Bearing: 


130 


Bearing: 


0 


Range: 


60 


Range: 


0 


Size: 


1 


Size: 


0 


Speed: 


600 


Speed: 


0 


Class: 


Hostile 


Class: 


Unknown 


Movement: 


Inbound 


Movement: 


Unknown 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (2): 


Fullop 


Fit Size: 


2 


Fit Size: 


2 


Location: 


ACAP 


Location: 


BCAP 


Avail Msls: 


6 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


0 


Assigned to TN: 


0 


Assigned to TN: 


0 



RECOMMENDATION: Attempt to engage threat (target 1) with HAWK missile 
when target is in range. Inform Stinger units of the situation. 
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File Number (10): Continuation file. Defense and weapon condition have 

upgraded. HAWK has been assigned to engage target. Target is still outside of 
HAWK's parameters. No other targets in the area. 



CURRENT A AW STATUS 



Defense Condition: 


Red 


Weapon Condition: 


Free 


Runway Status: 


OP 


Avail Fighter AC: 


9 


TAOC Status: 


OP 


Hawk Status: 


Assign 


Hawk Missile Inv: 


12 


Stinger Msl Inventory: 


20 




TARGET INFORMATION 




Track Number (1): 


4020 


Track Number (2): 


0 


Bearing: 


130 


Bearing: 


0 


Range: 


40 


Range: 


0 


Size: 


1 


Size: 


0 


Speed: 


600 


Speed: 


0 


Class: 


Hostile 


Class: 


Unknown 


Movement: 


Inbound 


Movement: 


Unknown 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (2): 


Fullop 


Fit Size: 


2 


Fit Size: 


2 


Location: 


ACAP 


Location: 


BCAP 


Avail Ms Is: 


6 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


0 


Assigned to TN: 


0 


Assigned to TN: 


0 


RECOMMENDATION: 


Continue to 


monitor HAWK target 


engagement. Update 


Stinger units on situation. 


Be prepared 


to flush airfield. 
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File Number (11): New file. High threat environment. Air defense missile 
inventory has decreased. The TAOC detects a section of low flying targets classified 
hostile. All assets are operational. 





CURRENT AAW STATUS 




Defense Condition: 


Red 


Weapon Condition: 


Free 


Runway Status: 


OP 


Avail Fighter AC: 


9 


TAOC Status: 


OP 


Hawk Status: 


OP 


Hawk Missile Inv: 


10 


Stinger Msl Inventory: 


18 




TARGET INFORMATION 




Track Number (1): 


4024 


Track Number (2): 


0 


Bearing: 


025 


Bearing: 


0 


Range: 


135 


Range: 


0 


Size: 


2 


Size: 


0 


Speed: 


450 


Speed: 


0 


Class: 


Hostile 


Class: 


Unknown 


Movement: 


Unknown 


Movement: 


Unknown 




FIGHTER INFORMATION 




Status (1): 


DEG 


Status (2): 


Fullop 


Fit Size: 


1 


Fit Size: 


1 


Location: 


ACAP 


Location: 


BCAP 


Avail Msls: 


4 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


0 


Assigned to TN: 


' 0 


Assigned to TN: 


0 



RECOMMENDATION: Attempt to engage threat (target 1) with fighter #1. If no 
kill prior to entrance of MEZ, break off assignment and engage with HAWK. Inform 
Stinger units of situation. 



51 



File Number (12): New file. High threat environment. The TAOC has detected 
two sections of target aircraft. A section of fighter aircraft is located at CAP 'A' while 



a single is at CAP 'B\ 










CURRENT AAW STATUS 




Defense Condition: 


Red 


Weapon Condition: 


Free 


Runway Status: 


OP 


Avail Fighter AC: 


9 


TAOC Status: 


OP 


Hawk Status: 


OP 


Hawk Missile Inv: 


10 


Stinger Msl Inventory: 


18 




TARGET INFORMATION 




Track Number (1): 


4027 


Track Number (2): 


4030 


Bearing: 


75 


Bearing: 


. 60 


Range: 


160 


Range: 


170 


Size: 


4 


Size: 


2 


Speed: 


480 


Speed: 


500 


Class: 


Asenemy 


Class: 


Hostile 


Movement: 


Inbound 


Movement: 


Inbound 




FIGHTER INFORMATION 




Status ( 1): 


Fullop 


Status (2): 


DEG 


Fit Size: 


2 


Fit Size: 


1 


Location: 


ACAP 


Location: 


BCAP 


Avail Msls: 


4 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


0 


Assigned to TN: 


0 


Assigned to TN: 


0 



RECOMMENDATION: Attempt to engage threat (target 2) with fighter #1 and 
(target 1) with fighter #2. If no kill prior to entrance of MEZ, break off assignment 
and engage with HAWK. Inform Stinger units of situation. 
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File Number (13): Continuation file. The TAOC has assigned the fighters to 
engage the hostile targets. The target movement continues to be inbound. The targets 
are still outside fighter weapon parameters. 

CURRENT AAW STATUS 



Defense Condition: 


Red 


Weapon Condition: 


Free 


Runway Status: 


OP 


Avail Fighter AC: 


9 


TAOC Status: 


OP 


Hawk Status: 


OP 


Hawk Missile Inv: 


10 


Stinger Msl Inventory: 


18 




TARGET INFORMATION 




Track Number (1): 


4027 


Track Number (2): 


4030 


Bearing: 


75 


Bearing: 


62 


Range: 


130 


Range: 


140 


Size: 


4 


Size: 


2 


Speed: 


480 


Speed: 


500 


Class: 


Hostile 


Class: 


Hostile 


Movement: 


Inbound 


Movement: 


Inbound 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (2): 


DEG 


Fit Size: 


2 


Fit Size: 


2 


Location: 


Assign 


Location: 


Assign 


Avail Msls: 


4 


Avail Msls: 


6 


Range to Tar_TN: 


25 


Range to Tar_TN: 


15 


Assigned to TN: 


4030 


Assigned to TN: 


4027 


RECOMMENDATION: 


Continue to monitor target engagement/s. 


If no kill prior to 



entrance of MEZ, break off with flight assignment and engage with HAWK. Update 
Stinger units. 
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File Number (14): Continuation file. Fighter #1 has expended all missiles while 
fighter # 2 has been shot down. Four targets have been destroyed while two continue 
inbound. 



CURRENT AAW STATUS 



Defense Condition: 


Red 


Weapon Condition: 


Free 


Runway Status: 


OP 


Avail Fighter AC: 


6 


TAOC Status: 


OP 


Hawk Status: 


OP 


Hawk Missile Inv: 


10 


Stinger Msl Inventory: 


18 




TARGET INFORMATION 




Track Number (1): 


4027 


Track Number (2): 


0 


Bearing: 


75 


Bearing: 


0 


Range: 


100 


Range: 


0 


Size: 


2 


Size: 


0 


Speed: 


500 


Speed: 


0 


Class: 


Hostile 


Class: 


Unknown 


Movement: 


Inbound 


Movement: 


Unknown 




FIGHTER INFORMATION 




Status (1): 


Fullop 


Status (2): 


Fullop 


Fit Size: 


1 


Fit Size: 


1 


Location: 


ACAP 


Location: 


ONRUN 


Avail Msls: 


0 


Avail Msls: 


6 


Range to Tar_TN: 


0 


Range to Tar_TN: 


0 


Assigned to TN: 


0 


Assigned to TN: 


0 



RECOMMENDATION: Attempt to engage threat (target 1) with HAWK missile 
when target is in range. Inform Stinger units of situation. 
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File Number (15): 
been severely damaged, 
inbound hostile targets. 

Defense Condition: 
Runway Status: 

TAOC Status: 

Hawk Missile Inv: 

Track Number (1): 
Bearing: 

Range: 

Size: 

Speed: 

Class: 

Movement: 

Status (1): 

Fit Size: 

Location: 

Avail Msls: 

Range to Tar_TN’: 
Assigned to TN: 



RECOMMENDATION: 
prepared to flush airfield. 



New file. The airfield runway and the HAWK battery have 
The TAOC, although degraded, has detected two raids of 



CURRENT AAW STATUS 




Red 


Weapon Condition: 


Free 


NonOP 


Avail Fighter AC: 


2 


DEG 


Hawk Status: 


NonOP 


3 


Stinger Msl Inventory: 


6 


TARGET INFORMATION 




4040 


Track Number (2): 


4042 


38 


Bearing: 


75 


45 ' 


Range: 


38 


4 


Size: 


4 


600 


Speed: 


500 


Hostile 


Class: 


Hostile 


Inbound 


Movement: 


Inbound 


FIGHTER INFORMATION 




DEG 


Status (2): 


Fullop 


1 


Fit Size: 


2 


CCAP 


Location: 


Onrun 


0 


Avail Msls: 


6 


0 


Range to Tar_TN: 


0 


0 


Assigned to TN: 


0 



Attempt to engage target/s with Stinger missile units. Be 
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C. EXPLANATION FACILITIES IN 'EXPERTAIR' 

'EXPERTAIR' contains an explanation facility which, on request, provides the 
decision-maker an opportunity to identify the data and sequence of rules utilized in 
deriving the final recommendations. The facility applies a hierarchical structure which 
allows a user to ascertain a desired level of detail of rule explanation. By continuing to 
request the facility to explain the given output, the user would ultimately obtain a list 
of all rules employed in the development of the decision. The following example of the 
explanation capability lists the derivation of the final decision to database file #7. 

EXPLAIN 

[How was neutr_action of air_defense-7 judged to be Cover threat (target 1) with 
fighter #1 and (target 2) with fighter #2 and attempt to determine intentions. If a 
hostile act is committed or if target enters the restricted area, then engage target. 
Inform HAWK and Stinger units of situation. (1.000) ? ] 

Since [1] the wepcon of status- 7 
is tight 

and [2] the tarl_bear of target-7 
is 50 

and 50 < 70 

and [3] the tarl_class of target-7 

is asenemy or unknown 
and [4] the tar2_bear of target-7 
is 130 

and [5] the tar2_class of target-7 

is asenemy or unknown 
and [6] the probl l_intercept of intercept-2 
is med or high 

and [7] the prob22_intercept of intercept-2 
is med or high 

then the neutr_action of the airdefense-7 is Cover threat (target 1) with fighter #1 and 
(target 2) with fighter #2 and attempt to determine intentions. If a hostile act is 
committed or if target enters the restricted area, then engage target. Inform HAWK 
and Stinger units of situation. 

EXPLAIN ( number of value ) ? 1 
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[ How was the wepcon of status-7 judged to be tight? ] 

• This value was determined by your response to a question (in the form of a data 
input). 

EXPLAIN ( number of value ) ? 2 

[ How was tart_bear of target-7 judged to be 50? ] 

• This value was determined by your response to a question (in the form of a data 
input). 

EXPLAIN ( number of value ) ? 3 

[ How was tarl_class of target-7 judged to be asenemy or unknown? ] 

• This value was determined by your response to a question (in the form of a data 
input). 

EXPLAIN ( number of value ) ? 4 

[ How was tar2_bear of target-7 judged to be 130? ] 

• This value was determined by your response to a question (in the form of a data 
input). 

EXPLAIN ( number of value ) ? 5 

[ How was tar2_class of target-7 judged to be asenemy or unknown? ] 

• This value was determined by your response to a question (in 'the form of a data 
input). 

EXPLAIN ( number of value ) ? 6 

The values of probl l_intercept of intercept-2 are : 

1) med / -1.0 

2) high / 1.0 

EXPLAIN ( number of value ) ? 2 

(for 'high') 

[ how was probl l_intercept of intercept-2 judged to be high? ] 

Since [1] the tarl_bear of target-7 
is 50 

and 50 < 70 

and [2] the tar l_range of target-7 
is 190 

and 190 > 119 

and [3] the tarl_move of target-7 

is inbound or closing 
and [4] the fitl_stat of fighter 
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is fullop 

and [5]the fitl_loc of fighter 

is onrun or en_cap or acap 
then the probll_intercept of the intercept-2 is high 
EXPLAIN ( number of value ) ? 7 
The values of prob22_intercept of intercept-2 are : 

1) med / -1.0 

2) high / 1.0 

EXPLAIN ( number of value ) ? 2 

(for 'high') 

[ How was prob22_intercept of intercept-2 judged to be high? ] 
Since [1] the tar2_bear of target 
is 130 

and 130 > 70 

and 130 < 140 

and [2] the tar2_move of target-7 
is 175 

and 175 > 119 

and [3] the tar2_move of target 

is inbound or closing 

and [4] the fit2_stat of fighter-3 
is fullop 

and [5] the fit2_loc of fighter-3 

is onrun or en_cap or bcap 
then the prob22_intercept of the intercept-2 is high 
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D. SUMMARY 



The execution of 'EXPERTAIR' consisted of evaluating fifteen database files 
which depicted events in a simulated air defense scenario. Each file was processed by 
identifying the input data in terms of concepts defined in 'EXPERTAIR's taxonomy 
file, comparing those concepts with the rules established in the rule base file, and 
displaying the resultant expert system conclusions. During the processing of the files, 
the input data w r as displayed on a terminal screen. At the completion of processing, 
the conclusions w r ere identified and displayed as system 'recommendations'. 
'EXPERTAIR's explanation facility provides the decision-maker an opportunity to 
identify the data and sequence of rules utilized in deriving the final recommendations. 
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V. FUTURE EXTENSIONS AND CONCLUSIONS 



A. OVERVIEW 

During the development of 'EXPERTAIR', the multiple parameters of the 
environment were bounded in order to keep the scope of the scenario within the realm 
of this thesis. However, now that the basic prototype has been constructed, the 
limitations imposed by this thesis can be gradually lifted for future development. The 
concepts and strategy that went into the development of 'EXPERTAIR' could allow 
for further research in three distinct areas: (1) A larger and more extensive air defense 
environment, (2) Training and tutoring of air defense personnel, and (3) Further 
incorporation of external sources. 

B. FUTURE AIR DEFENSE ENVIRONMENTS 

Now that the basic, expert system prototype has been developed, future research 
and continued maturation can expand the role, complexity, and usefulness of the 
weapons employment process model in the following areas: 

• Expand the air defense scenario to include an electronic warfare environment 
ana introduction of an anti-radiation missile threat 

• Development of an advanced screen display updating any parametric changes in 
the air defense scenario 

• Interface the system with atmospheric condition prediction systems 

• As an aid to other air defense missions to include surveillance and itinerant air 
traffic control 

’ 1. Expansion of Air Defense Scenario 

The air defense scenario that was used in development of the weapons 
employment process model was limited in scope. Follow-on research to the model 
could expand and increase the number of parameters interpreted and evaluated in an 
air defense environment. Incorporation of an electronic warfare environment and the 
threat of anti-radiation missiles are two areas where the model can be expanded. A 
broader environment and increasingly complex parameters that the model must 
consider may lead to the development of a full-scale expert system. 

2. Advanced Screen Display 

The development of 'EXPERTAIR' included a fundamental screen display for 
showing the results of the information that was being processed vis-a-vis database files. 
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A listing of the screen displays developed in 'EXPERTAIR' was presented in Chapter 
4. Utilizing the prototype, every time a new scenario was evaluated, a new screen 
would appear with the information that was processed, as well as a recommended 
course of action. A follow-on study could further develop the screen management to 
allow for continuous updating of information in the air defense environment. This new 
information could be highlighted in color or graphics to indicate intensity level and the 
situation of the hostile environment, giving visual aids to the operators of the system. 

3. Interface with Atmospheric Condition Predictions 

The prototype developed only dealt with weapons employment in a limited air 
defense environment. Further development could take into consideration changing 
atmospheric conditions which have an impact on the decisions to be made regarding 
the environment. The expert system prototype could be further developed to 
incorporate these atmospheric condition predictions for evaluation before a decision is 
made and a recommended course of action is given. 

4. Expansion of Man-Machine Interface 

The man-machine interface incorporated in 'EXPERTAIR' is very limited. 
The interface is through operator keyboard interaction, using the explanation facility of 
the expert system. This area could be greatly enhanced and expanded by using some 
alternative type of man-machine interaction such as voice recognition. Further 
development in this area could allow for the expert system model to be responsive to 
voice, both in giving and receiving information about a changing, environment. 

5. Additional Mission Aids 

'EXPERTAIR' could also be further designed and developed to aid other 
missions of an air defense unit. One area might be surveillance of an operating area 
where information is received via sensors and is interpreted and evaluated utilizing a 
rule base established on identification and classification criteria. Another mission 
where this prototype could be used or expanded includes the control of airborne 
itinerant aircraft. Data link instructions for transiting aircraft or aerial refuelers could 
be developed utilizing a traffic direction and control rule base. 

C. TRAINING AND TUTORING 

The expert system prototype which has been developed could be used with 
further research and development as an instructional/tutoring aid. With further 
expansion of the air defense parameters to simulate a more comprehensive combat 
environment, this prototype could help develop skills in the following areas: 
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• Situational analysis 

• Threat recognition 

• Target classification 

1. Situational Analysis 

'EXPERTAIR' could be expanded and developed in such a manner as to aid 
in the training of air defense personnel to recognize, interpret, and analyze information 
presented in a changing air defense environment. The student could then ascertain a 
course of action which would be checked against the recommendation given by the 
expert system. 

2. Threat Recognition 

Threat recognition training could be developed along the same avenue as the 
situational analysis objective. Students of air defense training could be taught to 
identify a changing air defense environment and recognize indications of threat 
advances/movement. 

3. Target Classification 

'EXPERTAIR' could also be developed to incorporate more information and 
rules about hostile targets. An extensive knowledge base, established on actual weapon 
systems platform parameters, could be developed as a viable training aid for air defense 
personnel allowing realistic training in the area of target analysis and classification. 

This prototype used in the training arena could be useful either as an 
individual tutoring/training device or in combat crew training. Expansion and 
development of this prototype would allow for ground training without the costly use 
of aircraft. Presently in the U.S. Marine Corps, there is a primary level of readiness in 
air defense qualification, however, advanced training is not at a level that might be 
obtained through the use and further development of expert systems technology. 

D. INCORPORATION OF EXTERNAL SOURCES 

The second objective of this thesis was to examine the feasibility of interfacing 
an expert system prototype with an external system. Our research and testing of this 
question was accomplished utilizing DBASE III Plus software as an external source of 
data input. Using DBASE III Plus software, a file was built containing information 
from one of the constructed air defense scenarios. This file was then converted by 
'EXPERTAIR' to draw the required inputs for processing and analysis and concluding 
with a recommended course of action to take. Our prototype was able to effectively 
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use this external source which gives further credibility to continued research and system 
expansion. Additional external systems could also be tested to interface with 
’EXPERTAIR' to include actual sensors gathering and receiving information about the 
environment. 

E. CONCLUSIONS 

The primary goal and emphasis area of this thesis was to determine the feasibility 
of using an expert systems approach to solve a problem in a non-repetitive stochastic 
environment. To accomplish this goal tw T o research questions were asked: 

1. Can an expert systems approach be applied to problems that are characterized 
by a non-repetitive stochastic environment? 

2. Can a developed expert system prototype be interfaced with an external system 
in order to provide the required inputs for processing and analysis? 

The first research question was answered by applying an expert systems approach to a 

weapons employment process model. The model development led to the establishment 

of a set of rules based upon a deterministic sequence of events in a controlled or 

bounded environment. An expert system prototype, 'EXPERTAIR', was then 

developed using database files which represented changing air defense scenarios. 

'EXPERTAIR' was found to produce accurate expert system conclusions based upon 

the data input. Although the rules in 'EXPERTAIR' make the system 'deterministic', 

the actual weapons employment process, itself stochastic in nature, may be evaluated 

using a combination or different sequencing of these rules. An expansion of the 

weapons employment process model and further development of 'EXPERTAIR's rule 

base could lead to a feasible system for 'solving problems and recommending solutions 

in a stochastic environment. . 

Our second research question dealt with interfacing a developed expert system 
prototype with a system existing external and independent of the prototype. To 
analyze this question, DBASE III Plus was used as the external system. A database 
file was built using DBASE III Plus and w r as interfaced with 'EXPERTAIR'. The 
prototype was successful in analyzing and processing the information contained in the 
external file and w r as able to ascertain a recommended course of action. This 
demonstrated that expert systems might be interfaced and be made operable with 
external systems (such as a TAOC) which gives credibility to the near-term 
implementation of an expert system. 
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APPENDIX A 

FRONT END FILE LISTING 



start 

nl, repeat, 

['convert, pl'l, convert, 
dbfile(Name), 

ifthenelse(Name = 'eof.db',stop,continu(Name)). 



continu(Name):- 

[Name], [[message!], 

[!run once!], 
gc(ftill), nl. 

abolish! status/8), 
abolismtarget/ 14), 
abolish! lighter/ 12), 
retract! dbTile( N ame)), 
fail. 



run_once:- 

root instance(airdefense,I,N). 
eval(neutr_action,airdefense,l,Val,true,CF), 

fail. 

run_once:- nl, nl. 

stop:- nl, write! This ends the scenario.'). 



dbfilei 

dbfile 

dbfile 

dbfile 

dbfile 

dbfile 

dbfile 

dbfile 

dbfile 

dbfile 

dbfile 

dbfile 

dbfile 

dbfile 

dbfile 

dbfile 



''xptl.db') 

'xpt2.db'j 

''xpt3.db') 

"xpt4-.db'1 

"xpt5.db') 

'xpt6.db') 

"xpt7.db' 

"xptS.db' 

"xpt9.db'). 

"xptlO.db' 

. 'xptll.db' 
'xptl2.db' 
'xptlldb' 
'xptld.db' 
'xptlo.db' 
'eof.db'). 



messaee:- 

(status!DC,WCJlS.AATS,HS,HM,SM): 
status!fDt.Wt,R^AATlH^.HM,SM])). 
(target(TNl^BRl^Rd^ 2 l,^Pl,CLl,MvY, TN2,BR2,RG2,SZ2, 

target([[TNl.BBLl,R(jl.SZl,SPl,CLl,MVl],[TN2,BR2,RG2,SZ2, 

SP2.CL2.MV2-)j. 

(fighter! ST 1 . FS 1 , LO 1 , AM i.TRT 1 , AT 1 ,ST2, FS2 . L02. AM 2. RT2, AT2): 
fig'hter![[STl,FSl,L01,AMl,RTl,ATl],[S'f2,FS2,L02,AM2,Rf2,AT^]])), 

nl, write!'*********** CURRENT AAW STATUS *******«■***'), 



nl.writefDEFENSE CONDITION : '), 
write( DC), 
write(' ), 

write 'WEAPON CONDITION : '), 
write WC). 

nl, write!' RUNWAY STATUS : '), 
write! RS), 
write!' '), 
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writef AVAILABLE FIGHTER AIRCRAFT : '), 
write} AAL 

nl.wntefTAOC STATUS : '), 

write(TS), 

writer '), 

write} 'HAWK STATUS : '), 

write HS), 

nl.wntef'HAWK MISSILE INVENTORY : '), 
write! HM), 



write! 



write} 'STINGER MISSILE INVENTORY : '), 
write(SM), 

nl,write(S*********** TARGET INFORMATION ***********S), 



nl, write! 'TRACK NUMBER 
write} TNT), 

NUMBER : '), 



write! 

writerTRAC 
write! TN2L 
nl.wnte('BEARING : '), 
write(BRl), 
write}' '), 

write}'BEARING : ), 
write} BR2), 
ni, writ ef RAN GE : '), 
write! RG1), 
write! ' '), 

write}'RANGE : '), 
write} RG2), 
nl, write! 'Sl£E : '), 
write! SZ1), 

write!' '), 

write} 'SIZE : '), 
write}sZ2). 
nl,wnte('SPEED : '), 
write! Sri), 
write!' '), 

write 'SPEED : '), 
write} SP2). 
nl,wnte( 'CLASS : '), 
write! C LI), 
write!' '), 

write}'CLASS : '), 
write}CL2), 

nl, write! ' M O VEMENT : '), 
write! MV 1), 
write}' T. 

write 'MOVEMENT : '), 
write} MV2), 

nl, write( ' * ********** FIGHTER INFORMATION 

nl.write! 'STATUS : '), 
write! ST 1), 

write(' '), 

write} 'STATUS : '), 
write} ST2). 

nl,wnte('FLT SIZE : '), 
write FS1), 

write(' '), 

write 'FLT SIZE : '), 
write FS2). 

nLwriterLOCATION : '), 
write! LOl), 
write!' '), 

write} 'LOCATION : '), 
write! L02), 

nl,wnte('AVAIL MSLS : ), 



**********'^ 
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write! AMI), 
writer '), 

writer AVAIL MSLS : 
write(AM2), 

nl, writer RANGE TO TAR_TN : '), 

write! RTl), 

write!' '). 

write 'RANGE TO TAR TN : '), 

write RT2). 

nl .writer AS SIGNED TO TN : '), 

writefATl), 

writer 

write 'ASSIGNED TO TN : '), 
write(AT2). 
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APPENDIX B 

'EXPERTAIR' CONVERT PROGRAM LISTING 



convert:- 



[dbasefor 'prdb.pl']. 

store_dbf( status 1 .dbf, 'status 1 .pi'), 

['status l.pl'L 

record(.[DC,WC,RS,AA,TS,HS,HM,SM]), 
create( Handle 1 ,'xpt l.db'J, 

write! Handle l,status(f DC, WC,RS,AA,TS,HS,HM,SM])), 

write( Handle 1,'.'), nl(Handlel), 

abolish(record/2J, 

store_dbf('targetl. dbf, 'targetl.pl'), 

P targetl.pl'], 
hndall(X record(Y,X),Ll. 
nl.write( Handle 1. target! L)), 
write(Handlel,'.'j, nf(Handlel), 
abolish(record/2J, 

store_db^ Tighter l.dbf, Tighterl.pl'), 

[Tighter l.pl'J, 

undall(X, record! Y,X),M), 

nl.write( ft andle 1 ,fi 2 hter( M )), 

write(Handlel '.'}, nl(fiandlel), 

close(Handlel), 

abolish( record/2). 
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APPENDIX C 

TAXONOMY FILE LISTING 



/*■ 



Type declarations 



tvpe svstem status_info = role, 
type target_Tnfo = role, 
type figKter_info = role, 
type airborne info = role, 
type interceprinfo = role. 

type defcon = [white, yellow, red]. 

type wepcon = [tight. free]. 

type runw_stat = fop, nonop]. 

type acft_avail = numeric. 

tvpe taoc stat = [op,deg,nonop]. 

type hawk_stat = [op, deg, nonop, assign]. 

tvpe hawk_msl = numeric. 

type stingjmsl = numeric. 



type tarl_tn = numeric, 
type tarl_bear = numeric, 
type tarl_range = numeric, 
type tarl_size = numeric, 
tvpe tarl_speed = numeric. 

type tarl class = [friend, asfriend, unknown, asenemy, hostile], 
type tarl_move = 

[unknown, inbound, outbound, closing, orbiting, opening], 
type tar2_tn = numeric, 
type tar2_bear = numeric, 
type tar2_range = numeric, 
type tar2_size = numeric, 
type tar2_speed = numeric. 

type tar2_class = [friend, asfriend, unknown, asenemy, hostile], 
type tar2_move = 

[unknown, inbound, outbound, closing, orbiting, opening]. 

type fitl_stat = [fullop,deg]. 
tvpe fitl_size = numeric. 

tvpe fitl_loc = [onrun t en_cap,acap,bcap,ccap, assign]. 

type fitl_msl = numeric. 

tvpe fitl_range_tar = numeric. 

tvpe litl_assign_tn = numeric. 

type fit2_stat = [fullop,deg]. 

type fit2_size = numeric. 

tvpe fit2_loc = [onrun t en_cap,acap,bcap,ccap, assign], ' 
type fit2_msl = numeric, 
type fit2_range_tar = numeric, 
type fit2_assign_tn = numeric. 

type airborne_tar = [zero, one, two], 
type airbome_fit = [zero, one, two]. 



type probl l_intercept = 
tvpe prob21_intercept = 
tvpe probl 2_intercept = 
type prob22_intercept = 



zero, low, med, high . 
zero, low, med, high', 
zero, low, med, high' . 
zero, low, med, high' . 



type neutr action = [csv,cst,cmta,cmte.cmhe,cwfl I,cwfl2,cwf21,cwf22, 
cfl 1 22, ell 22 1 ,ewfl l ,ewfl 2,ewf2 1 ,ewf22,ewh 1 ,ewh 1 2,ews,efl 1 22, eH 2 $ 1 
in ,in 2,xfa]. 
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Concept definitions 



define primitive airdefense with 
svstem status_info = status and 
tareet_Tnfo = tareet and 
fieKter_info = fishter and 
airbome_info = 'airborne and 
intercept info = intercept and 

neutr action = [ csv.cst.cmta.cmte.cmhe.cwfl I,cwfl2.cwf21,cwf22, 
cfTl 22, cH 22 1 .evvfl 1 ,ewfl 2,ewf2 l,ewf22,ewh 1 ,ewh 1 2,ew's,efl 1 22, 
efl221,lfl,lfl2,xfa]. 



define primitive status with 

defcon = [white.vellow,red] and 
wepcon = [tight Tree] and 
runvv stat = Top, nonop] and 
acft_avail = (0,y) and 
taoc stat = [op, dee, nonop] and 
hawk_stat = [op, deg, nonop, assign] and 
hawk msl = (0.15) and 
sting_msl = (0,24). 



(0,999) and 

[friend, asfriend, unknown, asenemy, hostile] and 



define primitive tareet with 
tarl tn = (400074777) and 
tarl_b ear = (0.359) and 
tarl range = (0.250) and 
tarl_size“= (0.12) and 
tar l_speed = 
tarl_class = 
tarl_move = 

[unknown.inbound, outbound, closing, orbiting, opening] and 
tarz_tn = (4000.4777) and 6 6 6 

tar2 bear = (0.359) and 
tar2 range = (0,250) and 
tar2 size = (0.1 2) and 
tar2_speed = (0,999) and 

tar2_class = [friend, asfriend, unknown, asenemy, hostile] and 
tar2_move = 

[unknown, inbound, outbound.closing, orbiting, opening]. 



define primitive fiehter with 
fit l_stat = [fulIop,deg] and 
fit l_size = (0,3) and 

fitl_loc = [onrun,en_cap,acap,bcap,ccap, assign] and 

fitl_msl = (0,S) and 

fitl ranee tar = (0.250) and 

fitl assign tn = (4000,4777) and 

lit2 stat = [fullop.deg] and 

fit2“size = (0.3) and 

fit2_loc = [onrun,en_cap,acap,bcap,ccap, assign] and 

fit2 msl = (0.8) and 

fit2 ranee tar = (0,250) and 

fit2“assigri^tn = (4000,4777). 



define primitive airborne with 

airborne_tar = (zero, one, two] and 
airborne_fit = [zero, one, two]. 



define primitive intercept with 



probl l_intercept = 
prob21_intercept = 
probl 2_intercept = 
prob22_intercept = 



zero, low, med.hieh 
zero, low, med.high 
zero. low’, med.hieh 
zero, low, med.high 



and 

and 

and 
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APPENDIX D 

RULE BASE FILE LISTING 



/* 

Control options 

_ */ 

report(neutr_action of airdefense) = SThe recommendation is:S. 

order!neutr_action of airdefense) = [rl. 

name? system status info of airdefense) = ignore. 

name! tar 2 et_fnfo ofairdefense) = ignore. 

name!fignter_info of airdefense) = ignore. 

name!airbome info ofairdefense) = ignore. 

name(interceprinfo ofairdefense) = ignore. 

precalc( status) = 

(defcon,wepcon,runw_stat,acft_avail,taoc_stat,hawk_stat, 
hawk_ms 1 , s t ing_msl] . 

question! cfefcon of status) = find defcon. 
question wepcon of status) = fin3_wepcon. 
question! runw_stat of status) = find_runw_stat. 
question!acft_avail of status) = find_acft_avail. 
question! taoc stat of status) = find taoc stat. 
question! ha\vk_stat of status) = find ha\vk_stat. 
question! hawk_msl of status) = findjia w k_msl. 
question! sting_msl of status) = find_sting_msl. 

setfsystem status info of the airdefense) = svstem_status_info. 
set!target_Tnfo ofThe airdefense) = tar 2 et_info. 
set!fignter_info of the airdefense) = fighter_info. 
set(airborne_info of the airdefense) = airborne info. 
set(intercept_info of the airdefense) = intercepr_info. 

precalc(target) = [tarl_tn,tarl_bear.tarl range, tarl_size, 

tarl_speedrtarl_class.tarl_move,tar2_tn,far2Jbear,tar2_range, 

tar2_size,tar2_speed,tar2_class,tar2_move]. 

question(tarl_tn of target) = find_tarl_tn. 
question! tarl_bear of target) = find tarl bear, 
question! tar l_ranae' of target) = find_tarT range. 
question!tarl_size w of target) = find_tarl size, 
question! tarl_speed of target) = find tarl_speed. 
question! tar l_class of target) = find Tarl class. 
question(tarl_move of target) = find tarf_move. 
question{tar2_tn of target) = find_tar2_tn. 
questionftar2_bear of target) = find tar2 bear, 
question! tar2_range of target) = find_tar2 range, 
question! tar2_size of target) = find_tar2 stze. 
question! tar2_speed of target) = find tar2_speed. 
question!tar2_class of target) = find Tar2 class, 
question^ tar2_move of target) = find^tar2^move. 

precalcf fighter) = [fit l_stat,fit 1 size.fitl loc.fitl msl, 
fitl_range tar,fitl_assign tn.fit2^stat.fit2^size,fit2_loc, 
fit2_msl7fif2_range_tar,Tit2_assign_tn]. 

question! fit l_stat of fighter) = find_fitl_stat. 
question!fitl_size of fighter) = find fit 1 size, 
question! fit l_loc of figTiter) = find Titl Toe. 
question! fit l_msl of fighter] = fincT_fitr msl. 
question! fit l_range_tar of fighter) = firid_fitl_range_tar. 
question! fit l_assign tn of fighter) = find_fitl_assign_tn. 
question(fit2_stat offighter) = find_fit2_stat. 
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question(fit2 size of fighter) = find fit2 size. 

»: >f 1 t2_loc offignter) = find Tit2 Toe. 

fit2_msl of fighter) = fin<r_fit2" msl. 
fit2_range_tar of fighter) = firid_fit2_range tar. 
fit2_assign_tn of fighter) = find_fit2_assign_tn. 



question 

question 

question 

question 



/*_ 



Synonyms 



■*/ 



%neutr_action 

synonym(csv) = SContinue normal surveillance; no immediate 
threat is present; no decision is required.S. 
synonym(cst) = SContinue surveillance of target/s. Launch (as 
required) to position fighters at CAP'S A & B. If 
a hostile act is committed, then engage target.S. 
synonym(cmta) = SContinue to monitor target alsignment/s. If 
a hostile act is committed, then engage target/s. 

Update HAWK and Stinger units.f. 6 
synonym(cmte) = SContinue to monitor target engagement/s. If 
no kill prior to entrance to MEZ. break off flight 
assignment and engage with HAWK. Update 
Stinger units. S. 

synonym(cmhe) = SContinue to monitor HAWK target engagement. 

L pdate Stinger units on situation. Be prepared to ' 
flush airfieldTS. 

synonym(cwfl 1) = SCover threat (target 1) with fighter £1 and 
attempt to determine intentions. If a hostile 
act is committed or if target enters the restricted 
area, then engage target. Inform HAWK and Stinger 
units of situafio'n.S. 

synonym(cw r fl2) = SCover threat (target 2) with fighter #1 and 
attempt to. determine intentions. If a hostile 
act is committed or if target enters the restricted 
area, then engage target. Inform HAWK and Stinger 
units of situafio'n.S. 



synonvm(cw r f21) = SCover threat (target 1) with fighter #2 and 
attempt to determine intentions. If a hostile 
act is committed or if target enters the restricted 
area, then engage target. Inform HAWK and Stinger 
units of situafio'n.S. 

synonym(cwf22) = SCover threat (target 2) with fighter £2 and 
attempt to determine intentions. If a hostile 
act is committed or if target enters the restricted 
area, then engage target. Inform HAWK and Stinger 
units of situation. S. 

svnonym(cfl 122) = SCover threat (taiget 1) with fighter #1 and 
(target 2) with fighter #Zand attempt to determine 
intentions. If a hostile act is committed or if 
target enters the restricted area, then engage target. 
Inform HAWK and Stinger units of situation. S. 
synonym(cf!221) = SCover threat (target 2) with fighter #1 and 
(target 1) with fighter #2and attempt to determine 
intentions. If a hostile act is committed or if 
target enters the restricted area, then engage target. 
Inform HAWK and Stinger units of situation.S. 
synonym(ewfll) = SAttempt to engage threat (target l) with 
fighter £1. If no kill prior to entrance 
to MEZ, break off assignment and engage with 
HAWK. Inform Stinger units of situation.S. 
synonvm(ewfl2J = SAttempt to engage threat (target 2) with 
fighter #1. If no kill prior to entrance 
to MEZ, break off assignment and engage with 
HAWK. Inform Stinger units of situation.S. 
synonym(ewf21) = SAttempt to engage threat (target l)with 
fighter U2. If no kill prior to entrance 
to MEZ, break off assignment and engage with 
HAWK. Inform Stinger units of situation.S. 
synonym(ew’f22) = SAttempt to engage threat (target 2) with 
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fighter #2. If no kill prior to entrance 
to MEZ, break off assignment and engage with 
HAWK. Inform Stinger units of situation.S. 

synonvm(ewhl) = S Attempt to engage threat (target 1) with HAWK 
missile when target is in range. Inform 
Stinger units of situation.S. 

synonym(efl 122) = SAttempt to engage threat (target 1) with 
fighter #1 ana (target z) with fighter #2. If 
no kill prior to entrance to MEZ. break off 
assignment and engage with HAWK. Inform 
Stinaer units of situation.S. 

synonym(efl221) = SAttempt to engage threat (target 2) with 
fighter #1 and (target!) with fighter #2. If 
no kill prior to entrance to MEZ. break off 
assignment and engage with HAWK. Inform 
Stinger units of situation.S. 

synonym(ewhl2) = SAttempt to engage threat (targets 1 & 2) with 
HAWK missile when targets are in range. 

Inform Stinger units of situation. Be 
prepared totlush airfield. S. 

synonym(ews) = SAttempt to engage target/s with Stinger missile 
units. Be prepared to flush airfield. S. 

synonym(lfl) = SLauncn fighter .#1 and assign to Cap C. 

Attempt to determine intentions of target. 

If target is identified as a possible threat, 
set Defense Condition to Yellow.S. 

synonym(lfl2) = S Launch fighter #1 and assign to Cap A. 

Launch fighter ??2 and assign to Cap B. Attempt 
to determine intentions of target. If target 
is identified as a possible threat, set Defense 
Condition to Yellow.S. 

synonym(xfa) = SCancel cover/engage assignment. Target is no 
longer an immediate threat. "Return fighters to 
CAR or return to base and replace as required.S. 



%Rule 1 

the airborne tar of airborne info is zero 
if 

the tarl size of target info is X and 
X < 1 and ~ 

the tar2 size of target info is Y and 

Y < 1. 

% Rule 2 

the airborne tar of airborne info is zero 
if " 

the tarl tn of target info is X and 

the tar2 tn of target info is Y and 

Y < 1. " 

% Rule 3 

the airborne tar of airborne info is one 
if " 

the tarl size of target info is X and 

the tar2 size of target info is Y and 

Y < 1. _ 

% Rule 4 

the airborne tar of airborne info is one 
if 

the tarl tn of target info is X and 
X > 1 and 

the tar2 tn of target info is Y and 

Y < 1. 6 ~ 

% Rule 5 

the airborne_tar of airborne_info is two 
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the tarl tn of target info is X and 
X > 1 and 

the tar2 tn of target info is Y and 

Y > 1. 

% Rule 6 

the airborne tar of airborne info is two 
if 

the tarl size of target info is X and 
X > 1 and ~ 

the tar2 size of target info is Y and 

Y > 1. 

% Rule 7 

the airborne fit of airborne info is zero 
if " 

the fitl_loc of fighter_info is onrun and 
the fit2_loc of fighter_info is onrun. 

% Rule 8 

the airborne fit of airborne info is one 
if ~ 

the fit 1 loc of fighter_info is 

|en_cap.acap,ccap, assign] and 
the fit2_loc of fighter_inio is onrun. 

% Rule 9 

the airborne fit of airborne info is two 
if ~ 

the fitl loc of fighter_info is 

|en_cap.a'cap. assign] and 
the fit2 loc of fighter_info is 
fen_cap,bcap, assign]. 

% Rule 10 

the probll_intercept of intercept_info -is zero 
if 

the tarl size of target info is X and 
X < 1. 



% Rule 11 

the probll_intercept of intercept_info is zero 
if 

the runw_stat of svstem status_info is nonop and 
the fitl_loc of fighter_inTo is onrun. 

%Rule 12 

the probl l_intercept of intercept_info is zero 
if 

the tarl range of target info is X and 
X < 10 and ~ 

the tarl speed of target info is Y and 
Y 350 and ~ 

the tarl move of target info is inbound and 
the fitljloc of fighter_info is onrun. 

% Rule 13 

the prob21_intercept of intercept_info is zero 
if 

the tarl range of target info is X and 
X < 10 and ~ 

the tarl speed of target info is Y and 
Y S 350 and " 

the tarl move of target info is inbound and 
the fit2_7oc of fighter_irifo is onrun. 

% Rule 14 

the probl l_intercept of intercept_info is zero 
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if 

the acft avail of system status info is X and 
X < 1. 

% Rule 15 

the prob2l_intercept of intercept_info is zero 
if 

the acft avail of system status info is X and 
X < 1. 



%Rule 16 . 

the probl l_intercept of intercept_info is zero 

if 

the fitl msl of fighter info is X and 
X < 1. " 



% Rule 17 

the prob21_intercept of intercept_info is zero 
if 

the fit2 msl of fighter info is X and 
X < 1. " 



%Rule 18 

the probl l_intercept of intercept_info is zero 
if 

the tarl ranee of target info is X and 
X < 65 and " 

the tarl speed ol target info is Y and 
Y 5- 400 and " 

the tarl move of target info is inbound and 
the fitljloc of fighter_irifo is [acap.ccapj. 



%Rule 19 

the prob21_intercept of intercept_info is zero 

the tarl range of target info is X and 
X < 65 and 

the tarl speed of target info is Y and 
Y > 400 and ~ 

the tarl move of target info is inbound and 
the fitljloc of fiehter_irifo is acap and 
the fit2_loc of fighter_info is bcap. 



% Rule 20 

the probl l_intercept of intercept_info is zero 
if 

the tarl range of target info is X and 
X < ^0 and “ 

the tarl speed of target info is Y and 
Y S 400 and " 

the tarl move of target info is [inbound, closing] and 
the fitljloc of fiehter info is acap and 
the fit 1 range tar of fighter info is Z and 
Z > 20 and 
Z < 50. 



% Rule 21 

the prob21_intercept of intercept_info is zero 
if 

the tarl range of target info is X and 
X < ^0 and " 

the tarl speed ol target info is Y and 
Y S 400 and ~ 

the tarl move of target info is [inbound, closing] and 
the Ht2Jtoc ol fiehter info is bcap and 
the fit2 range tar offiehter info is Z and 
Z>20and ~ 

Z < 50. 
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% Rule 22 

the probl l_intercept of intercept_info is zero 
if 

the tarl range of target info is X and 
X < /0 and 

the tarl speed of target info is Y and 
Y S> 400 and' “ 



the tarl move of target info is [inbound, closing] and 
the fitl Joe of fighter info is ccap and 
the fitl range tar of fighter info is Z and 
Z > 20 and " 

Z < 50. 



%Rule 23 

the probl l_intercept of intercept_info is low 
if 



the tarl range of target info is X and 
X > 10 and " 

X < 45 and 

the tarl move of target info is [inbound, closing] and 
the fitl Joe ol fighter_irifo is onrun. 



% Rule 24 

the prob21_intercept of intercept_info is low 
if 

the tarl range of target info is X and 
X > 10 and ' “ 

X < 25 and 

the tarl move of target info is [inbound, closing] and 
the fit2 Joe of fighter_irifo is onrun. 



% Rule 25 

the probl l_intercept of intercept_info is low 
if 

the tarl range of tafget info is X and 
X > 64 and “ 

X < 80 and 

the. tarl speed of target info is Y and 
Y > 400 and' " 



the tarl move of target info is inbound and 
the fit 1 Joe of fighter info is ccap and 
the fitl range tar of Tighter info is Z and 
Z < 2T. ” 



%Rule 26 

the probl ljntercept of interceptjnfo is low 
if 

the tarl range of target info is X and 
X > 69 and " 

X < 80 and 

the tarl speed of target info is Y and 
Y S 400 and “ 

the tarl move of target info is inbound and 
the fitl Joe of fighter info is ccap and 
the fitl range tar of fighter info is Z and 
Z > 20 and “ 

Z < 50. 



% Rule 27 

the probl ljntercept of intercept Jnfo is low 
if 

the tarl range of target info is X and 
X > 64 and 6 " 

X < 100 and 

the tarl speed of target info is Y and 
Y S 400 and 6 " 

the tarl move of target info is inbound and 
the fitl Joe of fighter' info is acap and 
the fitl_range_tar of fighterjnfo is Z and 
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Z < 21. 



% Rule 28 

the prob21_intercept of intercept_info is low 
if 

the tarl range of target info is X and 
X > 64 and 
X < 100 and 

the tarl speed of target info is Y and 
Y S 400 and “ 



the tarl move of target info is inbound and 
the fit2Jloc of fighter info is bcap and 
the fit2 range tar of Tighter info is Z and 
Z < 2T. ” 



% Rule 29 

the probl l_intercept of intercept_info is low 
if 

the tarl range of target info is X and 
X > / 9 and 
X < 100 and 

the tarl speed of target info is Y and 
Y £ 400 and " 



the tarl_move of target_info is inbound and 
the fit l_stat of fiehter info is deg and 
the fitl_loc of fighterjinfo is ccap. 



% Rule 30 

the probl l_intercept of intercept_info is low 
if 

the tarl range of target info is X and 
X > ^9 and “ 

X < 120 and 

the tarl speed of target info is Y and 
Y £ 400 and “ 



the tarl_move of target_info is inbound and 
the fitl_stat of fighter info is deg and 
the fitl_loc of figliterjinfo is acap. 



%Rule 31 

the prob21_intercept of intercept_info is low 
if 

the tarl range of target info is X and 
X > Y9 and 
X < 120 and 

the tarl speed of target info is Y and 
Y > 400 and 



the tarl_move of target_info is inbound and 
the fit2_stat of fighter info is deg and 
the fit2_loc of fighterjinfo is bcap. 



% Rule 32 

the prob21_intercept of intercept_info is med 
if 

the tarl bear of target info is W and 
W > 70 and" “ 

W < 140 and 

the tarl range of target info is X and 
X > 109 and " 

X < 120 and 

the tarl speed of target info is Y and 

the tarl_move of target_info is inbound and 

the fit2_stat of fighter info is fullop and 

the fit2_loc of fignterlnfo is bcap. 



% Rule 33 

the prob22_intercept of intercept_info is med 
if 
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the tar2 bear of target 
W > 70 ana 
W < 140 and 
the tar2 ran 

X > 

X < 120 and 



info is W and 



ge of target info is X and 
109 and ~ 




the tar2_move of target_info is [inbound,closing] and 
the fit2_stat of fighter info is fullop and 
the fit2_loc of fignterJTnfo is bcap. 



%Rule 34 

the probl l_intercept of intercept_info is med 
if 

the tarl bear of target info is W and 
W < 70 ancT " 

the tarl range of target info is X and 
X > 109 and ' 

X < 120 and 

the tarl speed of target info is Y and 
Y £ 400 and ~ 

the tarl_move of target_info is [inbound, closing] and 

the fit l_stat of fighter info is fullop and 

the fit l_loc of figliterJTnfo is acap. 



% Rule 35 

the probl 2_intercept of intercept_info is med 
if 

the tar2 bear of target info is W and 
W < 70 ana ~ 

the tar2 range of target info is X and 
X > 109 and 6 ~ 

X < 120 and 

the tar2 speed of target info is Y and 
Y S 400 and'' " 

the tar2_move of target_info is [inbound,closing] and 

the fit l_stat of fighter info is fullop and 

the fitl_loc of fighterJTnfo is acap. 



% Rule 36 

the probl l_intercept of intercept_info is med 
if 

the tarl range of target info is X and 
X > ^0 and " 

X < 110 and 

the tarl speed of target info is Y and 

the tarl_move of target_info is [inbound,closing] and 
the fit l_stat of fightel info is fullop and 
the fit l_loc of figTiterJinfo is ccap. 



% Rule 37 

the probl 2_intercept of intercept_info is med 
if 

the tar2 range of target info is X and 
X > ^0 and " 

X < 1 10 and 

the tar2 speed of target info is Y and 
Y S 400 and " 

the tar2_move of target_info is [inbound, closing] and 
the fit l_stat of fighter info is fullop and 
the fit l_loc of fignterjmfo is ccap. 



% Rule 38 

the probl l_intercept of intercept_info is med 

the tarl bear of target info is X and 
X < 70 and " 
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the tarl range of target info is Y and 

Y > 119 and ~ 

the tarl_move of target_info is [inbound, closing] and 
the fitl_stat of fighter info is deg and 
the fitl_loc of fig'hterjTnfo is acap. 

% Rule 39 

the probl2_intercept of intercept_info is med 
if 

the tar2 bear of target info is X and 
X < 70 and “ 

the tar2 range of target info is Y and 

Y > 119 and “ 

the tar2_move ol target_info is [inbound, closing] and 
the fit l_stat of fighter info is deg and 
the fit l_loc of fig'hterjTnfo is acap. 

% Rule 40 

the prob21_intercept of intercept_info is med 
if 

the tarl bear of target info is X and 
X > 70 and “ 

X < 140 and 

the tarl range of target info is Y and 

Y > 119 and ~ 

the tarl_move of target_info is [inbound, closing] and 
the lit2_stat of fighter info is deg and 
the fit2_loc of fig'hterjTnfo is bcap. 

% Rule 41 

the prob22_intercept of intercept_info is med 
if 

the tar2 bear of target info is X and 
X > 70 and " 

X < 140 and 

the tar2 range of target info is Y and 

Y > 119 and “ 

the tar2_move of target_info is [inbound, closing] and 
the fit2_stat of fighter info is deg and 
the fit2_loc of fig'hterjTnfo is bcap. 

% Rule 42 

the probll_intercept of intercept_info is med 
if 

the tarl range of target info is X and 
X > 109 and " 

the tarl_move ol target_info is [inbound, closing] and 
the fit l_stat of fighter info is deg and 
the fitl_loc of fignterjTnlo is ccap. 



% Rule 43 

the probll_intercept of intercept_info is high 
if 

the tarl bear of target info is X and 
X < 70 and ~ 

the tarl range of target info is Y and 
Y > 119 and “ 

the tarl_move of target_info is [inbound, closing] and 
the fitl_stat of fighter info is fullop and 
the fit 1 loc of fighter_info is 
fbnrun,en_cap,acap]. 



% Rule 44 

the probl2_intercept of intercept_info is high 
if 

the tar2 bear of target info is X and 
X < 70 and " 

the tar2 range of target info is Y and 
Y > 119 and " 
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the tar2_move of target_info is [inbound, closing] and 
the fitl_stat of fighter info is fullop and 
the fitl loc of fignterjmfo is 
Ionrun,en_cap,acap]. 



%Rule 45 

the prob21_intercept of intercept_info is high 
if 

the tarl bear of target info is X and 
X > 70 and “ 

X < 140 and 

the tarl range of target info is Y and 
Y > 119 and " 



the tarl_move of target_info is [inbound, closing] and 
the fit2_stat of fighter info is fullop and 
the fit2 loc of figliter Info is 
fonrun,en_cap7bcap]. 



% Rule 46 

the prob22_intercept of intercept_info is high 
if 

the tar2 bear of target info is X and 
X > 70 and 6 “ 

X < 140 and 

the tar2 range of target info is Y and 
Y > 119 and " 



the tar2_move of target_info is [inbound, closing] and 
the fit2_stat of lighter info is fullop and 
the fit2 loc of figTiter Info is 
]onrun.en_cap7bcap]. 



% Rule 47 

the probll_intercept of intercept_info is high 
if 

the tarl range of target info is X and 
X > 109 and " 

the tarl_move of target_info is [inbound, closing] and 
the fitl_stat of fighter info is fullop and 
the fitl loc of fighter_info is 
fbnrun,en_cap,ccap]. 



%Rule 48 

the probl2_intercept of intercept_info is high 
if 

the tar2 range of target info is X and 
X > 109 and 6 “ 

the tar2_move of target_info is [inbound, closing] and 
the fit l_stat of fighter info is fullop and 
the fitl loc of fighter_info is 
fonrun,en_cap,ccap]. 



% Rule 49 

the probl l_intercept of intercept_info is high 
if 

the tarl range of target info is X and 
X < ^00 and " 

the tarl_move of target_info is orbiting and 

the fit l_stat of lighter info is fullop and 

the fit l_loc of fig'hterjmfo is [en_cap,acap,ccap]. 

% Rule 50 

the neutr action of airdefense is csv 
if 

the defcon of system status_info is white and 
the airbome_tar of aTrborne_info is zero. 



%Rule 51 

the neutr action of airdefense is csv 
if 
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the defcon of system_status_info is white and 
the tarl_class of tareetjnfo is [friend, asfriend] and 
the airborne_tar of airbomejnfo is one. 

% Rule 52 

the neutr action of airdefense is cmta 
if" 

the tarl_class of target info is [unknown, asenemy] and 
the tarl move of targeF info is [inbound, closing] and 
the fit 1 Joe of fighter info is assign and 
the airbome_tar of airbomejnfo is one. 

% Rule 53 

the neutr action of airdefense is cmta 
if 

the tarl_class of target info is [unknown, asenemy] and 
the tarl_move of targeF info is [inbound, closing] and 
the tar2_class of target Info is [unknown, asenemy] and 
the tar2 move of targeF info is [inbound, closing]'and 
the fitljoc of fighter Jrifo is assign and 
the fit2Joc of fighterjnfo is assign. 

% Rule 54 

the neutr action of airdefense is emte 
if 

the tarl_class of target info is hostile and 

the tarl move of targeF info is [inbound, closine] and 

the fitljoc of fighter info is assign and 

the airbornejar of airbomejnfo is one. 

% Rule 55 

the neutr action of airdefense is emte 
if" 

the tarl_class of target info is hostile and 

the tarl_move of targeF info is [inbound, closing] and 

the tar2_class of target Info is hostile and 

the tar2 move of targeF info is [inbound, closing] and 

the fitljoc of fighter JriFo is assign and 

the fit2Joc of fighterjnfo is assign. 

%Rule 56 

the neutr action of airdefense is cmhe - 
if" 

the hawk stat of system status info is assign and 
the tarl_class of target info is [unknown, asenemv, hostile] and 
the tarl_move of targetjnfo is [inbound, closing] 'and 
the airbornejar of airbomejnfo is one. 

% Rule 57 

the neutr action of airdefense is Iff 
if" 

the defcon of system_status info is white and 
the runw_stat of system_staTus info is op and 
the aeft avail of system statuslnfo is X and 
X > 0 ana 

the airbornejar of airbomejnfo is one. 

% Rule 58 

the neutr action of airdefense is lfl 2 
if" 

the defcon of system status info is white and 
the runw_stat of sysfem_staTusJnfo is op and 
the aeft avail of system status info is X and 
X > 1 ana 

the airbornejar of airbomejnfo is two. 

% Rule 59 

the neutr action of airdefense is ewhl 
if" 
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the wepcon of svstem_status_info is free and 
the runw_stat of system_status_info is nonop and 
the hawk_stat of system_status info is fop, dee] and 
the hawk msl of svstem statuslnfo is w ancf 
\V“> 0 and 

the tarl bear of target info is X and 
X > 0 and " 

X < 140 and 

the tarl_class of target_info is [unknown, asenemy, hostile] and 
the airborne_fit of aTrbome_info is zero. 

%Rule 60 

the neutr action of airdefense is ewhl 
if 

the hawk_stat of system_status info is fop, deg] and 
the hawk msl of svstem status Info is X and 
X~> 0 and - 

the tarl_class of target_info is hostile and 
the airbome_tar of airborne info is one and 
the airborne fit of airbomejinfo is one and 
the probll_ihtercept of intercept_info is zero. 

%Rule 61 



the neutr action of airdefense is ewhl 




X“> 0 ancf 

the tarl_class of target_info is hostile and 
the airborne_tar of airborne info is one and 
the airborne fit of airbornejtnfo is two and 
the probl l_intercept of intercept_info is zero and 
the prob21_intercept of intercept_info is zero. 

%Rule 62 

the neutr action of airdefense is ewhl 2 
if" 

the hawk_stat of svstem_status_info is fop, deg] and 
the hawk msl of svstem status info is X and 
X“> 1 and" 

the tarl_class of target_info is hostile and 
the tar2_class of tar 2 et_info is hostile and 
the airborne_tar of airborne info is two and 
the airborne fit of airborneJTnfo is two and 
the probl l_intercept of intercept_info is zero and 
the prob21_intercept of intercept_info is zero and 
the probl 2_intercept of intercept_info is zero and 
the prob22_intercept of intercept_info is zero. 

%Rule 63 

the neutr action of airdefense is ews 
if" 

the hawk_stat of svstem_status info is nonop and 
the stina msl of svstem status Info is X ancf 
X"> 0 and 

the tarl_class of tar 2 et_info is hostile and 
the airborne_fit of aTrborne_info is one and 
the probl l_intercept of intercept_inlo is zero. 

% Rule 64 

the neutr action of airdefense is ews 
if" 

the hawk msl of svstem status info is X and 
X"< 1 ancf 

the stina msl ot svstem status info is Y and 
"T> 0 and 

the tarl_class of tar 2 et_info is hostile and 
the airborne fit of airborne_info is one and 
the probl l_mtercept of intercept_info is zero. 
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%Rule 65 

the neutr action of airdefense is cst 
if 

the defcon of system_status info is yellow and 
the runw_stat of system_staTus info is op and 
the acft avail of system status Info is X and 
X > 1 ana 

the tarl_class of target info is [asenemv, unknown] and 

the tarl_move of targeF info is [outbound, orbiting, opening] and 

the tar2_class of target Info is [asenemv, unknown] and 

the tar2_move of targeF_info is [outbound, orbiting, opening], 

%Rule 66 

the neutr action of airdefense is xfa 
if 

the tarl_class of target info is [asenemv, unknown] and 
the tarl_move of targeF info is Joutbound, opening] and 
the fitl range tar ofFighter info is X and 
X > 23 and 

the airbome_tar of airborne_info is one. 



%Rule 67 

the neutr action of airdefense is xfa 
if 



the tarl_class of target info is [asenemv, unknown] and 
the tarl_move of targeF info is Joutbound, opening] and 
the fit2 range tar ofTighter info is X and 
X > 23 and ~ 

the airborne tar of airborne info is one. 



%Rule 68 

the neutr action of airdefense is xfa 
if 



the tarl_class of target info is [asenemv, unknown] and 
the tarl_move of targeF info is [outbound, opening] and 
the tar2_class of target Info is [asenemv, unknown] and 
the tar2_move of targeF info is [outbound, opening] and 
the fitl range tar ofTigfiter info is X and 
X>23and " 

the fit2_ < range - tar of fighter_info is Y and 



%Rulo 69 

the neutr action of airdefense is cwfll 
if 



the wepcon of svstem status_info is tight and 
the tarl bear of targeF info is X and 
X < 70 and“ " 

the tarl_class of target_info is [asenemy, unknown] and 
the airborne_tar of airborne info is one and 
the airborne fit of airbornejlnfo is one and 
the probl l_intercept of intercept_info is [med.high]. 



%Rule 70 

the neutr action of airdefense is cwfl 1 
if 

the wepcon of svstem status_info is tight and 
the tarl bear of targeF info is X and 
X < 70 and 

the tarl_class of target_info is [asenemv, unknown] and 
the airborne_tar of airborne info is one and 
the airborne_fit of airbornejlnfo is two and 
the probl l_intercept of intercept_info is [med.high]. 



% Rule 71 

the neutr action of airdefense is cwf2l 
if 

the wepcon of system_status_info is tight and 
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the tarl bear of target info is X and 
X > 70 and 6 " 

X < 140 and 

the tarl_class of target_info is [asenemy, unknown] and 
the tar2_class of target info is [asenemy, unknown] and 
the tar2 move of targe! info is [outbound, orbiting.opening] and 
the pro621_intercept ofmtercept_info is [med.hign]. 

%RuIe 72 

the neutr action of airdefense is cw’f21 
if 

the w r epcon of svstem status info is tight and 
the tarl bear of targe! info is X and 
X > 70 and " 

X < 140 and 

the tarl_class of target_info is [asenemy, unknown] and 
the airbome_tar of airborne info is one and 
the airborne fit of airbomejinfo is two and 
the prob21_intercept of intercept_info is [med.high], 

% Rule 73 

the neutr action of airdefense is cwfl2 
if" 

the wepcon of system_status info is tight and 

the tarl_move o'f target info"is [outbound, orbiting, opening] and 

the tar2_class of tareetjtnfo is [asenemy, unknowm] and 

the airborne fit of aTrbome_info is one and 

the probl2_intercept of intercept_info is [med,high]. 

%Rule 74 

the neutr action of airdefense is cwfl2 
if 

the w’epcon of system_status_jnfo is tight and 
the tarl_move of target into is [outbound, orbiting, opening] and 
the ta r 2 bear of target Tnfo is X and 
X < 70 and " 

the tar2_class of target_info is [asenemv, unknown] and 

the airborne fit of airborne_info is tivo'and 

the probl2_intercept of intercept_info is [med.high]. 



% Rule 75 

the neutr action of airdefense is cfl 22 1 
if 

the wepcon of svstem status info is tight and 
the tarl bear of targe! info is X and 
X > 70 and " 

X < 140 and 

the tarl_class of targetjnfo is [asenemy, unknown] and 
the tar2 bear of target into is Y and 
Y < 70 and "• 



the tar2 class of tar, 
the pro612_intercep 



et info is [asenemy, unknown] and 



ofintercept_info is [med.high 



the prob2l_intercept of intercept_info is [med.high 



and 



% Rule 76 

the neutr action of airdefense is cfl 122 
if 

the wepcon of svstem status info is tight and 
the tarl bear of targe! info is X and 
X < 70 and 6 " 

the tarl_class of target_info is [asenemy, unknown] and 
the tar2 bear of target info is Y and 

Y > 70 and 

Y < 140 and 



the tar2 class of target info is [asenemy, unknowrn] and 
the probl l_intercept ofintercept_info is [med.high] and 
the prob22_intercept of intercept_info is [med.high]. 



% Rule 77 
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the neutr action of airdefense is ewfl 1 
if" 

the wepcon of system status info is free and 

the tarl_class of targel_info !s [unknown, asenemy, hostile] and 

the airbome_tar of airborne info is one and 

the airborne fit of airbornejinfo is one and 

the probl l_intercept of intercept_info is [med,high]. 

%Rule 78 

the neutr action of airdefense is ewfl 1 
if 

the wepcon of system status info is free and 
the tarl bear of targe! info is X and 
X < 70 and " 

the tarl_class of target_info is [unknown, asenemy, hostile] and 

the airbome_tar of airborne info is one and 

the airborne fit of airbornejlnfo is two and 

the probl i_ihtercept of intercept_info is [med,high]. 

% Rule 79 

the neutr action of airdefense is ewfl 1 
if 

the wepcon of system status info is free and 
the tarl bear of targe! info is X and 
X < 70 and " 

the tarl_class of target info is [unknown, asenemy, hostile] and 
the tar2_move of tarsefjnfo is [outbound, opening] and 
the airborne fit of airbome_info is two. and 
the probl l_intercept of intercept_info is [med,high]. 

%Rule 80 

the neutr action of airdefense is ewfl 1 
if" 

the wepcon of system status info is free and 

the tarl_class of targe! info Ts [unknown, asenemv, hostile] and 

the tar2_move of targef_info is [outbound, opening] and 

the airborne fit of airborne_info is one and 

the probl l_intercept of intercept_info is [med,high]. 

%Rule 81 

the neutr action of airdefense is ewf21 
if" 

the wepcon of system status info is free and 
the tarl bear of targe! info is X and 
X > 70 and " 

X < 140 and 

the tarl_class of tarset_info is [unknown, asenemy, hostile] and 
the airborne_tar of airborne_info is one and 
the airborne fit of airborne_info is two and 
the prob21_ihtercept of intercept_info is [med.high]. 

% Rule 82 

the neutr action of airdefense is ewf21 
if" 

the wepcon of system status info is free and 
the tarl bear of targe! info is X and 
X > 70 and " 

X < 140 and 

the tarl_class of target info is [unknown, asenemy, hostile] and 
the tar2_move of targe!_info is [outbound.opening] and 
the airborne_fit of airborne_info is two and 
the prob2 l_intercept of intercept_info is [med.high]. 

% Rule 83 

the neutr action of airdefense is ewfl 2 
if" 

the wepcon of svstem_status info is free and 

the tarl_move of target infols [outbound, opening] and 

the tar2_bear of target_fnfo is X and 
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X < 70 and 

the tar2_class of target_info is [unknown, asenemy, hostile] and 

the airborne fit of airborne_info is two and 

the probl2_intercept of intercept_info is [med,high]. 

% Rule 84 

the neutr action of airdefense is ewfl2 
if" 

the wepcon of svstem_status info is free and 

the tarl_move o'f target infols [outbound, openine] and 

the tar2_class of targetjmfo is [unknown, asenemy r , hostile] and 

the airborne fit of airbome_info is one and 

the probl2_intercept of intercept_info is [med,high]. 



% Rule 85 

the neutr action of airdefense is ewf22 
if" 

the wepcon of svstem_status info is free and 
the tan move o'f target infols X and 
X > 70 and " 

X < 140 and 

the tar2_class of tarsetjnfo is [unknown, asenemy, hostile] and 

the airborne fit of aTrborne_info is two and 

the prob22_mtercept of intercept_info is [med,high]. 

%Rule 86 

the neutr action of airdefense is efl 122 
if 

the wepcon of svstem status info is free and 
the tarl bear of targe! inlo is X and 
X < 70 and “ 

the tarl_class of tareet info is [unknown, asenemy, hostile] and 
the tar2 bear of target “info is Y and 

Y > 70 and " 

Y < 140 and 

the tar2 class of target info is [unknown.asenemv, hostile] and 



the probl l_intercept orintercept_info is 
the prob22_intercept of intercept_info is 



med,hieh] and 
med,high]. 



% Rule 87 

the neutr action of airdefense is efl 221 
if 

the wepcon of svstem status info is free and 
the tarl bear of targe! info is X and 
X > 70 and " 

X < 140 and 

the tarl_class of tareet_mfo is [unknown,asenemy, ho stile] and 
the tar2 bear of tareet info is Y and 



the 

the 

the 



Y < 70 and 
tar2 class of target 



jrifo is [unknown 



proU12_intercept ofintercept_info is 
prob21_intercept of intercept_info is 



asenemv.hostile] and 
med,high] and 
med,high]. 
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APPENDIX E 

CALCULATIONS FILE LISTING 



CALCULATIONS 



•7 



find_defcon( I .status,defcon, [DEFCON/ 1 .0]):- 
st a tus( DEFCON, 
status^DEFCON,^,^^ fx 

find_runw statXl,status.runwlifar,]TlTH^W_STAT/1.0]):- 



statusn , i). 
find_wepcon(r,status.wepconXWEPCON/ 1 .0]):- 
status( ,WEPCON, ,,,,,): 

^>p 7 t ’ nrrw , — 7 — — — 7 — — y t\ 



status(f .WEPCON" 7 7 



stafus! , ,RUNW STATUS, 
statusirr ,RUNW STATUS7777 7J). 
find acft availn, status, acfE avaiLfACFT" A vl AIL/ 1.0]):- 
” status! , , ,ACFT AVAIL, , , 
status (r’" " , ACFT A' VA I L 77 7 . ' 1). 
find taoc statfl.status.taoc stat.jTAOt” ST AT/ 1.0]):- 
" status! ,,, ,TAOC STAT,, , T 
status 7 7 7 7 ,TAOC STAlV 7 77). 
find hawk statX^sTalus.hawF staUfTAWK STAT/1.0]):- 
- status! , , .HAWK STAT, , ):" 
status(F 7 777 ,HAWK"STAT7 77). 
find_hawk msTCnsFaTus.hawk msl,[HAWK._MSL/1.0]):- 



statusfc"Y7^7’,HAWIC VISL’Tj). 
find_sting msl(f, stafus, sting mslJSTING_MSL/1.0]):- 
stalus! ,,,,,, , STING MSL): 
status^" F 7 7_7.STINC_M S L]). 

find_tarl_tn!I J tareet,tarl_tn,[TARl_TN/1.0]):- 

targetlTARlTN. 

find_tar l_5ear[ Ltarsel,tar’r’BeaF,]T^'Kl7Bfc^fr'r.oj):- 
target! ,TAR1 BEAR. ,,,,,,,,,, ,_); 
targetin .TART BEAR;^ " 77 77777 7 7,. II). 
find_tarl_rangej7,targer,tarl rar^eX^ARFJltATSTjrfe/T.O]):- 
targetr, ,TAR1 RANGE. 
target [£ ,TART RANGE; 7 7 7 7,7 7 7 7 7 7 ,_]])• 
find_tarl_size(barget.tafl size.[TXTn A7ZEH .DIJA “ 
target! . , ,TAR1 SIZE, , 
targetin'” "TART SIZE; 7 7 7.7 7 7 7 7 7. 11 ). 
find_tarl_speed(7;target.tafl speed.fiARrSi’fe^DTT-O]):- 
target( , , , ,TAR1 SPEED,, 
target([[7 7l7l,TART_SPEElX77,L7;77 77. ]]). 
find_tar l_class(I Target, tar 1 class,[TART_CLASsnrO]):- 
target! TAR7 CLASS. , , 

target([[ ,TART_C LASS; 7.7 



find tarl moveXT/target.tari moveJT ARi^OVE/T.t)]):- 
" target! , , , , , ,TAR1 MOVE. , 7 , , , , ); 
target [T 7 7777 ,TART MOVE1.F7 7 77 7 JD- 

find_tar2_tn!I,tafgetTar7_tn.[TAR2 TN, J f X$D:“ 

target! , TAR 2 T?v 

find tar 2 r §ear[T,Vaf g^CtarT? ’ R^fefc^/’nE] ) : - 

- target! , ,,,,,, TTAR2 BEAR ); 

target([[ 77 " 7 71,f .TAR2 BEAR77 7.7., 11). 

find tar2 range(7target;tar2 rangeJTAR.2 fo^TNCjfe/l.O]):- 

- targetf , , , , . , , 7.TAR2 RANGE. , , , ); 
target([[7_77_7 7_7J.7_._,TAR2_[U\NGT!7_7_7_._]]). 



S6 



find_tar2_ 

targeti 



,TARr CLAS‘ 



find fit 



find tar2 mov^i7tafg’et’,TaT2 mov’e^jl J AR2 MOVE/l’.O]):- 

- target} .-v_,_,_,:jarz MOVEV ;; 

find fitl sta^I.fishterXitl stat,[FITl_STAT/1.0]):- 
fight e r(HTl s JAT _, _,J; 
fighten [FITT STAG , . . .Tf . . , , .11). 
find fit 1 Nize(f, lighter, fit 1 size^Flfr S1ZE/T.D):- 
Tghten ,FIT1 SIZE.,, , , 7, , , ,J; 

*j!n s1( I $Tgft t e r Tt T "m sffF TTH^ 71 7)]): - ' 

;e t ar(T. fighter. fit 1 range far, 

RAiSGE TAk/l.t)]):- 8 _ 

T , , , ,FTT1 RANGE TAR. 

„ e (117 7 7 .FI TT RANGE TAR^J t r_7 777. J]). 

find fitl assign tnfrjfighter/fit 1 assign tn, 

FITPASSICjN' TNVi.OT):* " 
fightefl , , , , ,FIT1 ASSIGN TN, 
fighters 7 7 7 7 ,FITT ASSIGN TN1JV77 7, _]])• 
find fit2 stat(r.fig7ifer,Et2 staF,[FIT2 STAT YD\):- 

- lighten FIT2 STAT7 

fi t ^size ( I^fTgTi Fe r ,’fit it; T.O j)T^ ’ 



find 

find 

find 



[_fit2Toc(lV fignter7m2_locJFITZ LOCTlTjp:- 
hghterf , FI T2 TOC. 

fighter([f_, . , . , 7,7 , .PlT2 LOCT, .1]). 
_ fi 1 2Jms 1 ( l , figfi fe 7 Ft 2_m sT. fF IT 27 MS Lft iO]):- 

T J > * f » ^ 



fighter! 



- lighten , , , , , , 7FIT2 SIZE_ , ,_); 

fighter 117 - 777 J, [ ,FIT2 Sl^V’r j]). 
[_fit21oc( tteerTirri oc1nj2_LOOi76]j> 

,i » 1 j » F 

. Tgfifei 

■/ 

fit2 range tarft.ngmerTFuZ range tar, 

[FIT2 KANGF TAR/1.T)1):- “ 
fightef( ,,,,7,,,, ,FIT2 RANGE T 
‘ 7:7;7771^._,FIT2 RANGE. 
tn(T,nghTer,TiTi assign Fn, 

IFIT2'' ASSICjN TTs/1.0]):- " 

fightefl , ,FIT2 ASSIGN TN)‘ 

fighter l7l7j:7l7^ t7_7_7:,_,FIT2_ASSIGN_Tfs71). 



find fit2“assTgn-tnr v ’-’’^’ 



.ightefl 

fighter( 



IT2 "MSL, 

r 'IT2_M§T7_< 

nge_tar, 

T2 RANGE TAR, J; 

* ~_TAR,J1). 
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APPENDIX F 

DATABASE FILES LISTING 



Database XPT1 

*/ 



status( white.tieht,op,9,op,op, 1 2,20). 
target(0,0, 0.0,0, unknown, unknown, 

0,0, 0,0,0, unknown, unknown). 
fighter( fullop, 1 ,onrun,6,0,0,fullop, 1 ,onrun,6,0,0). 

/* 

Database XPT1 (converted) 

status([white ,tieht ,op ,9.0, op ,op ,12.0,20.01). ' 

tareet([[0.0.0.0,0.0j).0, 0.0, unknown .unknown UO.0, 0.0, 0.0, 0.0, 0.0, unknown .unknown ]]). 
fignter([[fuIlop , 1 .6,onrun ,6.0, 0.0, 0.0], [fullop ,1.6,onrun ,6.0, 0.0, 0.0]]). 

/* 

Database XPT2 

*/ 

status(white.tieht.op,9,op,op, 1 2,20). 
target(400 1 , 1 35,200, 1 ,350, asfriend, closing, 

0,0,0,0,0,unknown, unknown). 
fighter( fullop, 1 ,onrun, 6, 0,0, fullop, 1 ,onrun,6,0,0). 

r 

Database XPT3 

•/ 

status! white.tight.op,9,op, op, 1 2,20). 
target(4002, 110,1 85, 1 ,37o,asenemy, orbiting, 

0,0, 0.0, 0.unknown, unknown). 
fighter( fullop, 1 ,onrun,6, 0,0, fullop, 1 ,onrun,6,0,0). 

I* 

Database XPT4 

*/ 

/ 

status(yellow,tight.op,9.op,op, 1 2,20). 
target(4002, 1 16 . 1 So, 1 .375,asenemy,orbitin2, 

4003.028. 170. 2. 400, asenemy, orbuing). 
fighter(fullop, 1 ,ccap, 6, 0,0, fullop, 1 ,onrun,6,0,0J. 

/* 

Database XPT5 

*/ 

status(vellow.tieht.op,9,op,op,12,20). 
target(4002,l 10“1 70. L425,asenemv, inbound, 

4003.030. 1 90.2.400, aseriemv, outbound). 
fighter( fullop, 1 ,acap, 6, 0,(1, fullop, 1 ,bcap,6,0,0). 
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Database XPT6 



status(vellow,tieht,op,9.op,op,12,20). 
target(4002, 110, 1 75,1, 425, asenemv, outbound, 
0,0, 0,0,0, unknown, unknown), 
fighter! fullop l acap, 6,0,0, 

fullop, r, assign, 6,65, 4002). 

/* 

Database XPT7 

7 

status(vellow.tieht.op,9.op,op, 12.20). 
target(40 10.05071 90, 1.400, asenemv, inbound, 

40 12, 130, 1^5. 1.400, aseriemy, inbound), 
fight er( fullop, 1, acap, 6, 0,6, fullop, 1, bcap, 6, 0,0). 

/* 

Database XPT8 

7 

status! vellow.tieht. op, 9.op, op, 12,20). 
tarset(40 10,05071 80. 1,400, asenemv, inbound, 

40 1 2, 1 28, 1 65 , 1 .4 1 O.aseriemy, inbound). 
fighter( fullop, 1 , assign, 6, 78.40 10. 

fullop, 17assign,6,57,40 12). 



Database XPT9 



* / 



status! vellow.tisht,op.9.op, op. 1 2,20). 
target(4020, 1 30760. l,6o6, hostile. inbound, 

0,0 ,0 ,0 ,0 ,un kn own , unkn o wn ). 
fighter! fullop, 2, acap, 6, 0,0, fullop, 2, bcap, 6, 0,0). 



r 



Database XPT10 



status! red. free. op,9.op.assi2n, 12.20). 
target(4020, 1 30.56. 1 ,600. hostile. inbound, 

0,0, 0,0,0, unknown. unknown). 
fighter(fullop,2,acap,6,0,0,fullop,2,bcap,6,0,0). 

/* - 

Database XPT11 



status(red,free.op.9,op.op,10,18). 
tar2et(4024, 025, 130.27450, hostile, inbound, 
0.0 ,0,0,0, unknown, unknown). 
fighter(deg, 1 , acap, 4, 0,0, fullop, 1 , bcap, 6, 0,0). 

/* 



Database XPT12 



7 



status(red.free,op.9.op.op, 10, 1 8). 
target(4027, 75, Io6 .4 .480,asenemv. inbound, 
40trt 60 170 7 Wl hncfi e inhrmnr 



4’036, 60 ,170, 2, ’500, hosfile, inbound). 
lop,2,acap,4,0,0,de 

Database XPT13 



fighter! fullop, 2, acap, 4, 0,0, deg, 1, bcap, 6,0,0). 



7 
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status(red.free,op,9,op,op, 10, 1 8). 
target( 4027, 75, 1 56 A4$0, hostile, inbound, 

4036.62. 140. 2. 500, hostile, inbound), 
fighter! fullop, 2, assign, 4, 25.4030 

deg, 2, assign, 6, 1;>, 4027). 

/* 

Database XPT14 

*/ 

status! red. free, op. 6,op.op, 10, 1 8). 
target(4027, 75,106.2 ,o 60, hostile, inbound, 
0,0,0,0,0,unknown, unknown), 
fighter! fullop, l.acap, 0,0,0, 

fullop, F,onrun,6,0,0). 

/* 

Database XPT14 

*/ 

status! red. free, op,6,op,op, 10, 1 8). 
target! 4027, 75. 106. 5, 560, hostile.inbound, 
0,0.0,0.0,unknown,unknown). 
fighter! fullop l acap.0,0,0, 

fullop, r,onrun,6,0,0). 

/* 

Database XPT15 

*/ 

status! red. free, nonop,2, deg, nonop, 3, 6). 
target! 4040,38.45.4. oOO.hostile, inbound, 

4042. 75. 38. 4.500, hostile, inbound), 
fighter! deg, 1 , ccap, 0,0,0, fullop, 2, onrun, 6, 0,0). 
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APPENDIX G 

'EXPERTAIR' DICTIONARY 



airdefense 

the current air defense posture or environment as defined 
by data input identifying threat level, status of support and 
weapon systems, and airborne target and fighter characteristics 

defcon 

defense condition; level of readiness based upon projected 
imminence of a hostile attack; white delineates no expected 
attack; yellow anticipates attack in the near future; red 
indicates attack is in progress 

wepcon 

weapon condition; identifies weapon system rule of engage- 
ment; tiaht is defined in this model as engagement only in 
self defense; weapons Tree is the engagement of all targets 
not identified as Triend 

runw stat 

“runway status 

acft_avail 

aircraft availabilitv; identifies the total nunber of 
operational aircraft 

iaoc stat 

“ tactical air operations center status 
hawk stat 

IHAWK status; identifies the operational availabilitv of 
the IHAWK missile battery or a missile engagement assignment 

hawk msl 

“IHAWK missile availability; identifies the total number 
of missiles available for firing 

sting_msl 

stinger missile availability 



tar tn 

target track number; a manual or automatic computer 
assigned target identification code 

tar bear 

target bearing in degrees relative to system center/ 
vital area 

tar range 

target range in miles relative to system center/ 
vital area 

tar size 

target size; individual target track may include 
1 to 12 aircraft 

tar speed 

target speed in knots 
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tar class 

“ target classification; determined through fufillment 
of identification criteria to include authenticated 
communications, IFF modes and codes, stereo routes and 
corridors; valid classifications in this model include: 
friend, assumed friend, unknown, assumed enemy, and hostile 

tar move 

“ target movement relative to system center/vital area 
fit stat 

fighter status; degree of total system operability 
fit size 

” fighter size; individual fighter track may include 
1 to 3 aircraft 

fit loc 

” fighter location; valid entries include: on runway, 
enroute to CAP (holding station), 'A' CAP, B' CAP, 

C' CAP, and assigned to target 

fit msl 

” fighter missile; identifies the number of missiles being 
carried by designated fighter aircraft 

fit_range tar 

fighter range to target; identifies the range to a 
designated assigned target 

fit assign tn 

” fighters assigned target's track number 
airborne tar 

airborne targets; identifies the derived number of 
airborne targets in the area of responsibility 

airborne fit 

airborne fighter; identifies the derived number of 
airborne fighters in the area of responsibility 

prob intercept 

“probability of fighter aircraft completing an intercept 
on a target 

neutr_action 

neutralizing action conducted against target/s 
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APPENDIX H 
GLOSSARY 



antecedent 

The collection of goals in a rule that describe the conditions 
that must be true in order for the conclusion of the rule to be true. 

concept 

An idea or abstraction drawn from the specific. The basic unit 
of description of the items in the taxonomy. A concept can have 
characteristics or attributes which are represented by properties 
and roles. • F ' K F 

concept definition 

The description of a concept in the taxonomy file, 
consequent 

The conclusion of a rule, 
consultation 

A single run of the expert system, 
control options 

Optional features which allow the customizing of an expert system, 
definition 

A concept for w r hich there is a set of sufficient conditions 
w r hich define the concept. 

expert system 

A computer program which addresses problems for w r hich a 
programming algorithm cannot easily be defined. The air of an 
expert system isTo generate the same solution to a problem that 
a human would generate faced with the same problem. 

goal 

A hvpothesis. constructed from terms defined in a taxonomy, 
that is used in a rule. A condition that can be proved either 
true or not true. 

inexact reasoning 

Reasoning involving information of less than absolute certainty, 
inference 

A conclusion based on a premise, 
inference engine 

The part of a rule-based system that selects and executes rules, 
instance 

Created during a consultation, an 'instance' is an occurrance 
of a concept. 

knowledge base 

A collection of definitions and rules for use with an expert 
system. 

knowledge engineering 

The activities or software engineers who acquire knowledge 
for knowledge-based systems and decide how to represent it lor 
use in the system. 

primitives 

A concept for which guidelines exist, but for which an absolute 
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definition cannot be given. 

properties 

A quality of a concept. 



role 

A component of a concept. A role includes a value restriction 
and a number restriction. The value restriction of a role is another 
concept. 

rule base 

A collection of if-then rules that describe the interaction of 
the knowledge defined in the taxonomy. 

subsumption relationship 

A relationship of concepts whereby the properties and roles of 
one concept can be applied to another concept. The subsumed concept 
is a more specific subset of the subsuming concept. 

symbol 

A character string which stands for or suggests something 
by reason of relationship, association, convention, or 
accidental resemblance. 

system 

A group of interrelated elements, including ideas, principles, 
rules, and/or procedures, which form a collective entity. 

taxonomy 

A structured representation of the general information used 
in an expert system. The taxonomy structure incorporates subsumption 
relationships for allowing shared knowledge among the terms defined 
in the taxonomy. 

type declaration 

A statement placed at the beginning of a taxonomy file which is 
used to declare a property or role used in the taxonomy. 



94 



LIST OF REFERENCES 



1. Schumaker, Randall P. and Franklin, Jude, "Artificial Intelligence in Military 
Applications," Signal, June 1986. 



2. Simpson, Jr., Robert L., "Applications of AI Capabilities," Signal, August 1986. 



3. Boden, Margaret, Artificial Intelligence and Natural Man, Basic Books Inc., New 
York, 1977. 



4. Winston, Patrick H ..Artificial Intelligence, (2nd ed.), Addison-Wesley Publishing 
Company, Reading, Massachusetts, 1984. 



5. Scown, Susan, J., The Artificial Intelligence Experience: An Introduction, Digital 
Equipment Corporation, 1985. 



6. Davis, Randall and Lenat, Douglas B.. Knowledge-Based Systems in Artificial 
Intelligence, McGraw-Hill International Book Company, NewY'ork, 1982. 



7. Hayes-Roth, F., Waterman-, Donald A., and Lenat, Douglas B., eds., Building , 
Expert Systems , Addison-Wesley Publishing Company, Inc., Reading, 
Massachusetts, 1983. 



8.' Haves-Roth, Frederick, "Knowledge Based Expert Systems," Computer, October 



9. 



Fox. A., ed., Expert Systems State of the Art Report, Published by Pergamon 
InfoTech Limited, Maidenhead, Berckshire, England, 1984. 



10. FMFM 0-3, Doctrinal Publications Guide, U.S. Government Printing Office, 
Washington, D.C., July 1980. 



11. FMFM 5-5, Antiair Warfare, U.S. Government Printing Office, Washington, 
D.C., July 1980. 



95 



INITIAL DISTRIBUTION LIST 



1 . 



2 . 



3. 



4. 



5. 



6 . 



7. 



8 . 



9. 



Defense Technical Information Center 
Cameron Station 
Alexandria, VA 22304-6145 



Library. Code 0142 
Naval "Postgraduate School 
Monterey, CA 93943-5002 



Gary K. Poock, Code 55Pk 
Naval Postgraduate School 
Monterey, CA 93943-5000 



CAPT. Michael J. Molidor, USMC 
Rt. 2 Box 321 
Frisco, TX 75034 



CDR. J. Stewart, Code 55ST 
Naval Postgraduate School 
Monterey, CA 93943-5000 



C3 Academic Group, Code 74 
Prof. M. K. Sovereign 
Naval Postgraduate School 
Monterey, CA 93943-5000 



Naval War College 
Wareamine Department 
S inis'" Ha 11, T 109 
Newport, RI 02841-5010 



MAJOR T. J: Brown, USAF 
Code 39 • 

Naval Postgraduate School 
Monterey, CA 93943-5000 



Capt. Stephen P. Dodd, USMC 
10334 Londonderry Rd 
Houston, Tx 77043 



10. T.R. Sivasankaran 
Admin Sciences 54SJ 
Naval Postgraduate School 
Monterey, Ca 93943-5000 



No. Copies 
2 



2 



1 



2 



2 



2 



1 



1 



3 



3 



96 



jOUDjjTV^' T 



♦ 4 ** ' i 






T 



n kTY 




Dodd 

An exQ&rt systems ap- 
to military deci- 
5n support in an air 
defense scenario. 



'TT^r 

301 



thesD6155 

An expert systems approach to military d 




3 2768 000 72604 6 
DUDLEY KNOX LIBRARY 







